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Presentacion 



Acerca del libro 

Este libro busca brindar a estudiantes y docentes de las carreras de inge- 
nieria en computacion, informatica, Ciencias de la Computacion y similares un 
material completo, general y autocontenido sobre la materia de sistemas opera- 
tivos. No se asiraie conocimiento previo sobre la tematica, aimque se utilizaran 
conceptos de estructuras de datos y algoritmos basicos. 

Justificacion 

Actualmente hay vasta bibliografia sobre sistemas operativos, sin embargo 
la gran mayoria esta escrita en ingles, y cuando estan disponibles en castellano, 
su traduccion deja mucho que desear, Uevando a conceptos confusos y diflci- 
les de comprender. La intencion de los autores es que el presente texto provea 
un material redactado originaLmente en castellano, revisado por docentes lati- 
noamericanos utilizando la terminologla mas adecuada para los alumnos de la 
region y eliminando muchos de los errores de traduccion. 

Generalmente el material de cursos de sistemas operativos esta compues- 
to por partes de distintos libros, articulos de investigacion, recursos en linea, 
software, ejercitacion, etc. Por ello, el alumno debe recurrir a distintas fuentes 
durante el curso. El presente libro pretende ser de utilidad tanto para alumnos 
como para docentes como ima linica publicacion autocontenida. Cabe remar- 
car tambien que el material bibUografico generalmente esta protegido por de- 
recho de autor, es costoso y en muchos casos de dificil acceso (sobre todo las 
publicaciones en ingles). 

Los contenidos de la bibliografia clasica de sistemas operativos estan basa- 
das en re-ediciones y compendio de libros de hace varias decadas que incluyen 
temas obsoletos o desactualizados. Hay tambien desarroUos y tendencias nue- 
vas en el area que aiin no han sido integradas en la bibliografia clasica, y mucho 
menos a las traducciones. Tambien se quiere revisar y actualizar los conceptos 
clasicos de sistemas operativos inlcuyendo material de publicacion reciente. 
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CAPITULOO. PRESENTACION 



Este libro se desarrollo dentro del marco del Proyecto LATIn, enfocado a la 
creacion de libros de texto con un esquema de licenciamiento libre, derivados 
de la creacion y colaboracion de grupos de trabajo miiltinacionales, para la 
region latinoamericana. 

Publico objetivo 

Este libro esta apuntado tanto a estudiantes de carreras de informatica, 
computacion e ingenierias como a los aficionados de la computadora interesa- 
dos en conocer un poco mas de lo que realmente ocurre dentro de un sistema 
de computo y el papel que cumple el sistema operativo. 

Al finalizar el libro se espera que el lector haya adquirido conocimientos y 
habilidades como: 

■ Administrar, disenar y desarrollar un sistema operativo. 

■ Conociendo el funcionamiento general de los sistemas operativos, poder 
sacar mejor provecho de la computadora 

■ Conocer y saber aprovechar no solo los sistemas, sino las metodologias y 
principales formas de interaccion del software libre 

Se asume tambien que el lector esta familiarizado con algiin lenguaje de 
programacion de alto nivel, y -al menos en un nivel basico- con C. Aunque 
los ejemplos de codigo estan dados en diversos lenguajes de programacion 
(Bash, Perl, c, PascalFC, Python, Ruby, Ensamblador, entre otros), estos son tan 
sencillos que pueden ser facilmente escritos en el lenguaje de eleccion del lector 
sin mayor esfuerzo. 

Resultara muy conveniente que tener acceso a vma computadora con siste- 
ma operativo Liniix (GNU) u otro Unix libre. 

Estructura tematica 

El texto comprende los siguientes capftulos: 

1. Introduccion. Para comenzar a hablar de sistemas operativos, es necesario, 
en primer termino, enmarcar que es \m sistema operativo y cuales son 
sus funciones principales. Tambien es importante detallar algunos pun- 
tos que, contrario a la percepcion comiin, no pueden considerarse parte de 
sus ftmciones. 

Este tema se presenta apoyado en la evolucion historica del computo, ha- 
ciendo entasis en por que este proceso evolutive en particular desemboco 
en los sistemas operativos que se tienen hoy en dia. 
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2. Relacion con el hardware. Partiendo de que una de las principales tareas 

del sistema operativo es presentar una abstraccion regular del hardware a 
los procesos que se ejecuten, resulta importante presentar como este esta 
estructurado, y como el sistema operativo puede comimicarse con el. 

Este capitulo aborda la jerarqma de almacenamiento, el mecanismo de inte- 
rrupciones y excepciones y el papel que desempenan para las Uamadas al sis- 
tema, las caracteristicas base de diversos tipos de dispositivo del sistema, 
el concepto de canales (o buses) de comunicacion, el mecanismo de acceso 
directo a memoria, y una introduccion a un tema que puede ser visto como 
eje conductor a lo largo de todo el libro: La importancia y complejidad de 
la concurrencia, y su relacion con el paralelismo y multiprocesamiento. 

3. Administracion de procesos. La entidad principal con la que interactiia un 

sistema operativo (ya sea para brindarle servicios o para imponerle res- 
tricciones) es el proceso. Este capitulo inicia presentando los diferentes 
estados de los procesos y la relacion entre estos y sus hermanos meno- 
res (los hilos), y los principales modelos empleados para el miiltiproce- 
samiento. 

Todos los sistemas operativos modernos tienen que enfrentar a la concu- 
rrencia: la incertidumbre del ordenamiento en el tiempo entre eventos re- 
lativos a los diferentes procesos e hilos. La parte medular de este capitulo 
presenta a las primitivas de sincronizacion: mutexes, semaforos y monito- 
res. Para ilustrarlas, se emplean los patrones y problemas clasicos que se 
han seguido a lo largo de su desarrollo historico. 

Pero las primitivas pueden solamente utilizarse entre procesos que coope- 
ran deliheradamente entre sf. Un sistema operativo debe instrumentar pro- 
teccion y separacion, incluso entre procesos que compiten o que sencilla- 
mente no saben el uno acerca del otro. Por eUo, la ultima seccion de este 
capitulo aborda los diferentes mecanismos que hay para evitar las situa- 
ciones de bloqueo mutuo. 

4. Planificacion de procesos. Para que varios procesos coexistan en un sistema 

de computo, el primer recurso que el sistema operativo debe multiplexar o 
repartir entre todos ellos es el tiempo de computo: el uso del procesador. 
Este capitulo presenta los diferentes niveles de planificador que forman 
parte de un sistema operativo, y analiza al planificador a corto plazo (tam- 
bien conocido como despachador). Se presentan los principales algoritmos, 
y se ilustra como los sistemas operativos modernos van empleando tec- 
nicas mixtas de varios de ellos. 

Por ultimo, se abordan tres temas brevemente: los diferentes modelos de 
planificaci6n de hilos y su relacion con los procesos, las particularidades 
de la planificacion en un entorno con miiltiprocesadores reales, y las ne- 
cesidades de planificacion de tiempo real. 



14 



CAPITULOO. PRESENTACION 



5. Administracion de memoria. Los programas solo se vuelven procesos cuan- 

do se les asigna memoria y tiempo de computo: cuando dejan de ser el 
resultado de una compilacion guardada estaticamente para convertirse 
en una entidad dinamica. Este capitulo presenta, en primer lugar, la vi- 
sion desde dentro de la memoria por parte de cada uno de los procesos: el 
espacio de direccionamiento y el acomodo clasico de las regiones de \m 
proceso en la memoria que le es asignada. 

Para que los distintos procesos compartan la memoria del sistema, vemos 
que a lo largo de la historia se han presentado diferentes esquemas. Se 
explican someramente los esquemas de particion contigua fija y variable, 
para profundizar posteriormente en los que ofrecen mayor flexibilidad al 
sistema operativo y se mantienen en uso al dia de hoy: la segmentacion 
y la paginacion. De esta ultima, se continua para presentar la abstraccion 
que ha Uberado a los sistemas operativos para sobrecomprometer la memo- 
ria de forma eficiente y practicamente transparente: la memoria virtual. 

Al manejar la memoria de un proceso surgen puntos importantes a to- 
mar en cuenta en lo relativo a la seguridad en computo; la parte final 
de este capitulo presenta la vulnerabilidad conocida como desbordamiento 
de buffer {buffer overflow), y algunas estrategias de mitigacion que se han 
implementado con el paso de los anos para mitigar su peligrosidad. 

6. Organizacion de archives. De cara al usuario, probablemente la principal 

abstraccion Uevada a cabo por el sistema operativo es la organizacion de 
la informacion sobre tm medio persistente. Hoy en dia, la norma es que 
esta organizacion se realice en archivos estructurados sobre una estructura 
jerarquica Uamada directorio. Este capitulo se centra en explicar esta abs- 
traccion, sin entrar aiin en detalles respecto a como se llega a un respaldo 
flsico de la misma. 

Estos conceptos parecen tan omnipresentes y universales que podrfa pen- 
sarse que no requieren mayor analisis. Sin embargo, resulta importante 
abordar las diferencias semanticas derivadas del desarrollo historico de 
distintos sistemas. En este capitulo se presentan varios conceptos cuya 
instrumentacion en un medio que asegure la persistencia se describira en 
el siguiente capitulo. 

Por ultimo, se incluye un breve repaso de distintos tipos de sistemas de 
archivos en red, enfatizando nuevamente en los cambios semanticos de- 
rivados de la distinta historia de cada instrumentacion. 

7. Sistemas de archivos. Este capitulo presenta la contraparte obligada del an- 

terior: ^como se estructuran los dispositivos de almacenamiento a largo 
plazo, a los cuales se hace referenda genericamente como discos, como se 
van plasmando las estructuras mediante las cuales el usuario organiza la 
informacion en bloques dentro de wx dispositivo, que problemas pueden 
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derivar del uso de estos sistemas de archivos, y que metodos para evitarlos 
o resolverlos se han implementado? 

Este capitulo basa sus ejemplos en un sistema de archivos bastante viejo 
y simple, pero aiin en muy amplio uso en el computo moderno: la famUia 
FAT. 

Los siguientes temas resultan muy importantes para la comprension y para 
el desarrollo futuro de la materia, pero dado que son empleados por el siste- 
ma operativo (y no necesariamente son parte integral del mismo), se presentan 
como apendices 

A. Software libre y licenciamiento. Estudiar sistemas operativos cruza nece- 

sariamente la tematica del software libre. Uno de los principios fundamen- 
tales del desarrollo historico es la libertad de aprender, esto es, todo softwa- 
re que se diga libre debe permitir a sus usuarios comprender sus estructu- 
ras basicas, la relacion entre ellas, y la logica general de su programacion. 

Hoy en dfa hay una gran cantidad de sistemas operativos libres, tanto 
de proposito general como enfocados a un nicho. El movimiento ideoldgico 
del software libre, contrario a cualquier pronostico que pudiera haber- 
se hecho al iniciarse en 1984, claramente ha cambiado el desarrollo del 
computo. Todos los sistemas operativos que pueden ser estudiados de 
primera mano, constatando la instrumentacion de sus principios son nece- 
sariamente (aunque con una definicion ligeramente laxa) software libre. 

Hacia el ano 2000 se fue haciendo claro que estas ideas no pueden apli- 
carse unicamente al software. Poco a poco fue definiendose una nocion 
mucho mas amplia, la de los bienes culturales libres. El presente libro busca 
brindar una contribucion a esta ultima categoria. 

El primer apendice aborda brevemente estos temas, as! como los princi- 
pales modelos de licenciamiento libre utilizados. 

B. Virtualizacion. La virtualizacion es una herramienta muy litil, y esta cada 

vez mas al alcance de todos, para el aprendizaje de los sistemas opera- 
tivos. Hay una gran cantidad de recursos para comprender desde los 
primeros momentos del arranque de la computadora. Empleando ima- 
genes de maquinas virtuales, pueden comprenderse y desmenuzarse los 
distintos elementos del sistema operativo, e incluso observar el resultado 
de realizar modificaciones sobre un sistema operativo real. Es, por tanto, 
ima herramienta muy importante para acompanar al aprendizaje de esta 
materia. 

La virtualizacion es tambien una tecnologia que permea cada vez mas 
aspectos del uso profesional del computo, y comprenderlo ayudara al 
lector a elegir las herramientas especificas a emplear. 



16 



CAPITULOO. PRESENTACION 



Pero hablar de la virtualizacion como un todo ignoraria aspectos funda- 
mentales de la riqueza que presenta este campo. Al igual que con los 
conceptos presentados a lo largo del libro, la virtualizacion es presenta- 
da a partir de su perspectiva historica, y detallando hacia las distintas 
modalidades que se han desarrollado con el paso del tiempo. 

C. El medio fisico y el almacenamiento. En el capitulo 7 se presenta como se 
concretiza la abstraccion de archivos y directorios para plasmarlo en un 
gran arreglo lineal de datos, en una entidad aiin abstracta a la cual se si- 

gue haciendo referenda con el nombre generico de disco. Este apendice se 
ocupa de los detalles fisicos del acomodo de la informacion en su medio. 

Pero un disco va mucho mas alia de un dispositivo que simplemente vuel- 
ca dicho arreglo a un medio persistente. En primer termino, los discos 
magneticos rotativos (el medio dominante de almacenamiento) presentan 
peculiaridades que los sistemas operativos tuvieron que saber resolver. 
El desarrollo de la tecnologia, sin embargo, fue arrebatando estas areas del 
ambito del sistema operativo, entregandolas a la optimizacion reaUzada 
dentro del hardware controlador. 

Por otro lado, la tecnologia de almacenamiento en estado solido ha Uega- 
do a niveles de madurez que en determinados mercados ya la colocan 
claramente por encima de los discos magneticos. Esto implica cambios 
importantes para el modo en que el sistema operativo debe estructiirar y 
modificar la informacion. 

Por ultimo, \m volumen ya no necesariamente se refiere a un linico medio 
fisico. Este apendice aborda tanto a raid, el primer mecanismo que se 
popularize para agregar varias unidades para mejorar, tanto la capacidad 
maxima y la confiabilidad de un volumen, como al manejo avanzado de 
volumenes, en que el sistema operativo incorpora la logica de raid con 
la del manejo de sistemas de archivos para lograr mucho mayor flexibili- 
dad. 

Licenciamiento 

Este libro fue desarrollado como parte del Proyecto LATln, que busca la 
creacion de libros de texto libres para nivel universitario, y enfocado a Latinoa- 
merica. 

Cualquier parte de este libro puede ser reproducido y utilizado para todo 
fin, bajo los terminos de la licencia Creative Commons-Atribucion-Compartirlgual 
(CC-BY-SA) version 4.0. 

Este modelo de licenciamiento se presenta y explica en la seccion A.2.1. 



Capitulo 1 

Introduccion 



1.1. ^Que es un sistema operative? 

El sistema operativo es el principal programa que se ejecuta en toda compu- 
tadora de proposito general. 

Los hay de todo tipo, desde muy simples hasta terriblemente complejos, y 
entre mas casos de uso hay para el compute en la vida diaria, mas variedad 
habra en ellos. 

A lo largo del presente texto, no se hace referenda al sistema operativo co- 
mo lo ve o usa el usuario final, o como lo vende la mercadotecnia — el ambiente 
grafico, los programas que se ejecutan en este, los lenguajes de programacion 
en los cuales est^n desarrollados y en que mas faciknente se puede desarrollar 
para ellos, e incluso el conjunto basico de funciones que las bibliotecas base 
ofrecen son principabnente clientes del sistema operativo — se ejecutan sobre 
el, y ofrecen sus interfaces a los usuarios (incluidos, claro, los desarroUadores). 
La diferencia en el uso son solo -cuando mucho- consecuencias del diseno de 
un sistema operativo. Mas aiin, con el mismo sistema operativo -como pue- 
den constatarlo comparando dos distribuciones de Linux, o incluso la forma 
de trabajo de dos usuarios en la misma computadora- es posible tener entornos 
operativos completamente disimiles. 

1.1.1. ^Por que estudiar los sistemas operativos? 

La importancia de estudiar este tema radica no solo en comprender los me- 
canismos que emplean los sistemas operativos para cumplir sus tareas sino 
en entenderlos para evitar los errores mas comunes al programar, que pueden 
resiiltar desde un rendimiento deficiente hasta perdida de informacion. 

Como desarroUadores, comprender el funcionamiento basico de los siste- 
mas operativos y las principales alternativas que ofrecen en muchos de sus 
puntos, o saber disenar algoritmos y procesos que se ajusten mejor al sistema 



17 



18 



CAPITULOl. nSfTRODUCCldN 



operativo en que vayan a ejecutarse, puede resultar en una diferencia cualita- 
tiva decisiva en el producto final. 

Parte de las tareas diarias de los administradores de sistemas incluye en- 
frentarse a situaciones de bajo rendimiento, de conflictos entre aplicaciones, 
demoras en la ejecucion, y otras similares. Para ello, resulta fundamental com- 
prender lo que ocurre tras bambalinas. Los sistemas de archives resultan vin 
area de especial interes para administradores de sistemas: icomo comparar las 
virtudes y desventajas de tantos sistemas existentes, per que puede resultar 
conveniente mezclar distintos sistemas en el mismo servidor, como evitar la 
corrupcion o perdida de informacion? Lo que es mas, ^como recuperar infor- 
macion de un disco danado? 

En el area de la seguridad informatica, la relacion resulta obvia. Desde el 
punto de vista del atacante, si le interesa localizar vulnerabilidades que permi- 
tan elevar su nivel de privilegios, ^como podria lograrlo sin comprender como 
se engranan los diversos componentes de un sistema? La cantidad de tareas 
que debe cubrir un sistema operativo es tremenda, y se veran ejemplos de si- 
tios donde dicho atacante puede enfocar sus energias. Del mismo modo, para 
quien busca defender un sistema (o una red), resulta fundamental comprender 
cuales son los vectores de ataque mas comunes y -nuevamente- la relacion en- 
tre los componentes involucrados para poder remediar o, mejor aiin, prevenir 
dichos ataques. 

Y claro esta, puede verse al mundo en general, f uera del entomo del compu- 
to, como tma serie de modelos interactuantes. Muchos de los metodos y algo- 
ritmos que se abordan en esta obra pueden emplearse fuera del entomo del 
computo; una vez comprendidos los problemas de concurrencia, de compe- 
tencia por recursos, o de proteccion y separacion que han sido resueltos en el 
campo de los sistemas operatives, estas soluciones pueden ser extrapoladas a 
otros campos. 

El camino por delante es largo, y puede resultar interesante y divertido. 

1.2. Funciones y objetivos de los sistemas operati- 
ves 

El sistema operativo es el linico programa que interactiia directamente con 
el hardware de la computadora. Sus funciones primarias son: 

Abstraccion Los programas no deben tener que preocuparse de los detalles de 
acceso a hardware, o de la configuracion particular de una computadora. 
El sistema operativo se encarga de proporcionar una serie de abstraccio- 
nes para que los programadores puedan enfocarse en resolver las nece- 
sidades particulares de sus usuarios. Un ejemplo de tales abstracciones 
es que la informacion esta organizada en archivos y directorios (en uxio o 
muchos dispositivos de almacenamiento). 
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Administracion de recursos Una sistema de computo puede tener a su dis- 
posicion una gran cantidad de recursos (memoria, espacio de almacena- 
miento, tiempo de procesamiento, etc.), y los diferentes procesos que se 
ejecuten en el compiten por ellos. Al gestionar toda la asignacion de recur- 
sos, el sistema operative puede implementar polfticas que los asignen de 
forma efectiva y acorde a las necesidades establecidas para dicho sistema. 

Aislamiento En im sistema multiusuario y multitarea cada proceso y cada 
usuario no tendra que preocuparse por otros que esten usando el mis- 
mo sistema — IdeaLmente, su experiencia sera la misma que si el sistema 
estuviera exclusivamente dedicado a su atencion (aunque fuera \m siste- 
ma menos poderoso). 

Para implementar correctamente las funciones de aislamiento hace falta 
que el sistema operative utUice hardware especifico para dicha protec- 
cion. 

1.3. Evolucion de los sistemas operatives 

No se puede comenzar a abordar el tema de los sistemas operatives sin revi- 
sar brevemente su desarrollo historico. Esto no solo permitira comprender por 
que fueron apareciendo determinadas caracterfsticas y patrones de diseno que 
se siguen empleando decadas mas tarde, sino (como resulta particularmente 
bien ejemplificado en el discurso de recepcion del premio Turing de Fernan- 
do Corbato en 1990, On building systems that will fail), adecuar un sistema a 
un entorno cambiante, por mejor disenado que este estuviera, Ueva casi inevi- 
tablemente a abrir espacios de comportamiento no previsto — el espacio mas 
propicio para que florezcan los f alios. Conocer los factores que motivaron a los 
distintos desarroUos puede ayudar a prever y prevenir problemas. 

1.3.1. Proceso por lotes (batch processing) 

Los antecedentes a lo que hoy se conoce como sistema operative pueden 
encentrarse en la autematizacion inicial del procesamiento de diferentes pro- 
gramas, surgida en los primeros centres de compute: cuande en los anes cin- 
cuenta aparecieren los dispesitives perferaderes/lecteres de tarjetas de papel, 
el tiempo que una computadora estaba improductiva esperando a que estu- 
viera lista una tarea (como se designaba a una ejecucion de cada determinado 
programa) para poder ejecutarla disminuyo fuertemente ya que los programa- 
dores entregaban su lote de tarjetas perforadas (en ingles, batches) a los ope- 
radores, quienes las alimentaban a los dispositivos lectores, que lo cargaban 
en memoria en un tiempo razonable, iniciaban y monitoreaban la ejecucion, y 
producian los resultados. 
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En esta primer epoca en que las computadoras se especializaban en tareas 
de calculo intensive y los dispositivos que interactuaban con medios externos 
eran practicamente desconocidos, el papel del sistema monitor o de control era 
basicamente asistir al operador en la carga de los programas y las bibliotecas 
requeridas, la notificacion de resultados y la contabilidad de recursos emplea- 
dos para su cobro. 

Los sistemas monitores se fueron sofisticando al implementar protecciones 
que evitaran la corrupcion de otros trabajos (por ejemplo, lanzar erroneamen- 
te la instruccion leer siguknte tarjeta causaria que el siguiente trabajo encolado 
perdiera sus primeros caracteres, corrompiendolo e impidiendo su ejecucion), 
o que entraran en un ciclo infinito, estableciendo alarmas {timers) que interrum- 
pirian la ejecucion de un proceso si este duraba mas alia del tiempo estipulado. 
Estos monitores implicaban la modificacion del hardware para considerar di- 
chas caracteristicas de seguridad — y ahi se puede hablar ya de la caracteristica 
basica de gestion de recursos que identifica a los sistemas operativos. 

Cabe anadir que el tiempo de carga y puesta a punto de una tarea seguia 
representando una parte importante del tiempo que la computadora dedicaba 
al procesamiento: un lector de cintas rapido procesaba del orden de cientos de 
caracteres por minuto, y a pesar de la lentitud relativa de las computadoras 
de los anos cincuenta ante los estandares de hoy (se medirian por miles de 
instrucciones por segundo, KHz, en vez de miles de millones como se hace hoy, 
GHz), esperar cinco o diez minutos con el sistema completamente detenido 
por la carga de un programa moderadadamente extenso resulta a todas luces 
un desperdicio. 

1.3.2. Sistemas en lotes con dispositivos de carga {spool) 

Una mejora natural a este ultimo pimto fue la invencion del spool: un me- 
canismo de entrada/ salida que permitla que una computadora de proposito 
especifico, mucho mas economica y limitada, leyera las tarjetas y las fuera con- 
virtiendo a cinta magnetica, un medio mucho mas rapido, teniendola lista para 
que la computadora central la cargara cuando terminara con el trabajo ante- 
rior. Del mismo modo, la computadora central guardarba sus resultados en 
cinta para que equipos especializados la leyeran e imprimieran para el usuario 
solicitante. 

La palabra spool (bobina) se tomo como acronimo inverso hacia Simultaneous 
Peripherial Operations On-Line, operacion simultanea de perifericos en Imea. 

1.3.3. Sistemas multiprogramados 

A lo largo de su ejecucion, un programa normaLmente pasa por etapas con 
muy distintas caracteristicas: durante un ciclo fuertemente dedicado al calculo 
niraierico, el sistema opera limitado por el CPU (C7\J-bound), mientras que al leer 
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o escribir resultados a medios externos (incluso mediante spools) el limite es im- 
puesto por los dispositivos, esto es, opera limitado por entrada-salida {I-O bound). 
La programacion miiltitareas o los sistemas multiprogramados buscaban ma- 
ximizar el tiempo de uso efectivo del procesador ejecutando varios procesos al 
mismo tiempo. 

El hardware requerido cambio fuertemente. Si bien se esperaba que cada 
usuario fuera responsable con el uso de recursos, resulto necesario que apare- 
ciera la infraestructura de proteccion de recursos: un proceso no debe sobrees- 
cribir el espacio de memoria de otro (ni el codigo, ni los datos), mucho menos 
el espacio del monitor. Esta proteccion se encuentra en la Unidad de Manejo de 
Memoria (MMU), presente en todas las computadoras de uso generico desde los 
anos noventa. 

Ciertos dispositivos requieren bloqueo para ofrecer acceso exclusivo/iini- 
co: cintas e impresoras, por ejemplo, son de acceso estrictamente secuencial, y 
si dos usuarios intentaran usarlas al mismo tiempo, el resultado para ambos se 
corromperia. Para estos dispositivos, el sistema debe implementar otros spools 
y mecanismos de bloqueo. 

1.3.4. Sistemas de tiempo compartido 

El modo de interactuar con las computadoras se modifico drasticamente 
durante los anos sesenta, al extenderse la multitarea para convertirse en siste- 
mas interactivos y multiusuarios, en buena medida diferenciados de los anterio- 
res por la aparicion de las terminales (primero teletipos seriales, posteriormente 
equipos con una pantalla completa como se conocen hasta hoy). 

En primer termino, la tarea de programacion y depuracion del codigo se 
sitnplifico fuertemente al poder hacer el programador directamente cambios y 
someter el programa a la ejecucion inmediata. En segundo termino, la compu- 
tadora nunca mas estaria simplemente esperando a que este listo un progama: mien- 
tras un programador editaba o compilaba su programa, la computadora segula 
calculando lo que otros procesos requirieran. 

Un cambio fundamental entre el modelo de multiprogramacion y de tiempo 
compartido es el tipo de control sobre la miiltitarea (se vera en detalle en el 
capltulo 3 Administracion de procesos). 

Multitarea cooperativa o no apropiativa {Cooperative multitasking). La imple- 
mentaron los sistemas multiprogramados: cada proceso tenia control del 
CPU hasta que este hacia una Uamada al sistema (o indicara su disposicion 
a cooperar por medio de la llamada yield: ceder el paso). 

Un calciilo largo no era interrumpido por el sistema operativo, en conse- 
cuencia mv error de programador podia congelar la computadora com- 
pleta. 

Multitarea preventiva o apropiativa {Preemptive multitasking). En los sistemas 
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de tiempo compartido, el reloj del sistema interrumpe periodicamente a 
los diversos procesos, tvansiiviendo forzosamente el control nuevamente al 
sistema operativo. Este puede entonces elegit otro proceso para continuar 
la ejecucion. 

Ademas, fueron naciendo de forma natural y paulatina las abstracciones 
que se conocen hoy en dia, como los conceptos de archivos y directorios, y el c6- 
digo necesario para emplearlos iba siendo enviado a las bibliotecas de sistema y, 
cada vez mas (por su centralidad) hacia el niicleo mismo del, ahora si, sistema 
operativo. 

Un cambio importante entre los sistemas multiprogramados y de tiempo 
compartido es que la velocidad del cambio entre una tarea y otra es mucho 
mas rapido: si bien en un sistema multiprogramado un cambio de contexto podia 
producirse solo cuando la tarea cambiaba de un modo de ejecucion a otro, en 
un sistema interactivo, para dar la ilusion de uso exclusivo de la computadora, 
el hardware emitia periodicamente al sistema operativo interrupciones (senales) 
que le indicaban que cambie el proceso activo (como ahora se le denomina a \ma 
instancia de un programa en ejecucion). 

Diferentes tipos de proceso pueden tener distinto nivel de importancia — ^ya 
sea porque son mas relevantes para el funcionamiento de la computadora mis- 
ma (procesos de sistema), porque tienen mayor carga de interactividad (por 
la experiencia del usuario) o por diversas categorfas de usuarios (sistemas con 
contabilidad por tipo de atencion). Esto requiere la implementacion de diver- 
sas prioridades para cada uno de estos. 



1.4. Y del lado de las computadoras personales 

Si bien la discusion hasta este momento asume una computadora central 
con operadores dedicados y multiples usuarios, en la decada de los setenta 
comenzaron a aparecer las computadoras personales, sistemas en un inicio verda- 
deramente reducidos en prestadones y a ujn nivel de precios que los ponlan al 
alcance, primero, de los aficionados entusiastas y, posteriormente, de cualquie- 
ra. 

1.4.1. Primeros sistemas para entusiastas 

Las primeras computadoras personales eran distribuidas sin sistemas ope- 
rativos o lenguajes de programacion; la interfaz primaria para programar- 
las era mediante llaves {switches), y para recibir sus resultados, se utilizaban 
bancos de LEDs. Claro esta, esto requeria conocimientos especializados, y las 
computadoras personales eran aiin vistas solo como juguetes caros. 
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Figura 1.1: La microcomputadom Altair 8800, primera computadora personal con dis- 
tribucion masiva, a la venta a partir de 1975 (imagen de la Wikipedia: Altair 8800). 

1.4.2. La revolucion de los 8 bits 

La verdadera revolucion aparecio cuando, poco tiempo mas tarde, comen- 
zaron a venderse computadoras personales con salida de video (tlpicamente 
por medio de una television) y entrada por un teclado. Estas computadoras 
popularizaron el lenguaje BASIC, disenado para usuarios novatos en los sesen- 
ta, y para permitir a los usuarios gestionar sus recursos (unidades de cinta, 
pantalla posicionable, unidades de disco, impresoras, modem, etc.) llevaban 
im software mlnimo de sistema — ^nuevamente, un proto-sistema operativo. 



Figura 1.2: La Commodore Pet 2001, en el mercado desde 1977, una de las primeras 
con interprete de BASIC (imagen de la Wikipedia: Commodore PET). 



1.4.3. La computadora para fines "serios": la familia PC 

Al aparecer las computadoras personales "serias", orientadas a la oficina 
mas que al hobby, a principios de los ochenta (particularmente representadas 
por la IBM PC, 1981), sus sistemas operativos se comenzaron a diferenciar de los 
equipos previos al separar el entorno de desarrollo en algun lenguaje de progra- 
macion del entorno de ejecucion. El papel principal del sistema operativo ante el 
usuario era administrar los archivos de las diversas aplicaciones mediante una 
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sencilla interfaz de Imea de comando, y lanzar las aplicaciones que el usuario 
seleccionaba. 

La PC de IBM fue la primer arquitectura de computadoras personales en 
desarrollar una amplia familia de clones, computadoras compatibles disefiadas 
para trabajar con el mismo sistema operativo, y que eventualmente capturaron 
casi 100% del mercado. Practicamente todas las computadoras de escritorio y 
portatiles en el mercado hoy derivan de la arquitectura de la IBM PC. 



Figura 1.3: La computadora IBM PC modelo 5150 (1981), iniciadora de la arquitec- 
tura predominantemente en uso hasta el dia de hoy (imagen de la Wikipedia: IBM 
Personal Computer). 

Ante las aplicaciones, el sistema operativo (PC-DOS, en las versiones dis- 
tribuidas directamente por IBM, o el que se popularize mas, MS-DOS, en los 
clones) ofrecla la ya conocida serie de interfaces y abstracciones para adminis- 
trar los archivos y la entrada/ salida a traves de sus puertos. Cabe destacar que, 
particularmente en sus primeros anos, muchos programas se ejecutaban direc- 
tamente sobre el hardware, arrancando desde el BIOS y sin emplear el sistema 
operativo. 

1.4.4. El impacto del entorno grafico (wiMP) 

Hacia mediados de los ochenta comenzaron a aparecer computadoras con 
interfaces usuario graficas {Graphical User Interfaces, textscguis) basadas en el 
paradigma WIMP {Windows, Icons, Menus, Pointer; Ventanas, Iconos, Menues, 
Apuntador), que permitlan la interaccion con varios programas al mismo tiem- 
po. Esto no necesariamente significa que sean sistemas multitarea: por ejemplo, 
la primer interfaz de MacOS permitla ver varias ventanas abiertas simultanea- 
mente, pero solo el proceso activo se ejecutaba. 

Esto comenzo, sin embargo, a plantear inevitablemente las necesidades de 
concurrencia a los programadores. Los programas ya no tenlan acceso directo 
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Figura 1.4: Apple Macintosh (1984), popularize la interfaz usuario grafica (GUI) 
(imagen de la Wikipedia: Macintosh). 

a la pantalla para manipular a su antojo, sino que a una abstraccion (la ven- 
tana) que podia variar sus medidas, y que requeria que toda la salida fuera 
estrictamente mediante las llamadas a bibliotecas de primitivas graficas que 
comenzaron a verse como parte integral del sistema operative. 

Ademas, los problemas de proteccion y separacion entre procesos concu- 
rrentes comenzaron a hacerse evidentes: los programadores teman ahora que 
programar con la conciencia de que compartirian recursos, con el limitante 
(que no teman en las maquinas profesionales) de no contar con hardware es- 
pecializado para esta proteccion. Los procesadores en uso comercial en los 
ochenta no manejaban anillos o niveles de ejecucion ni unidad de administracion 
de memoria (MMU), por lo que un programa fallado o danino podia corromper 
la operacion completa del equipo. Y si bien los entomos que mas exito tuvie- 
ron (Apple MacOS y Microsoft Windows) no implementaban multitarea real, si 
hubo desde el principio sistemas como la Commodore Amiga o la Atari ST que 
hacian un multitasking apropiativo verdadero. 

Naturalmente, ante el uso comun de un entorno de ventanas, los progra- 
mas que se ejecutaban sin requerir de la carga del sistema operative cayeron 
lentamente en el olvido. 

1.4.5. Convergencia de los dos grandes mercados 

Conforme fueron apareciendo los CPU con caracteristicas suficientes en el 
mercado para ofrecer la proteccion y aislamiento necesario (particularmente. 
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Figura 1.5: Commodore Amiga 500 (1987), la computadora mas popular de la fa- 
milia Amiga, con amplias capacidades multimedia y multitarea apropiativa; ima 
verdadera maravilla para su momento (imagen de la Wikipedia: Amiga). 

Intel 80386 y Motorola 68030), la brecha de funcionalidad entre las computado- 
ras personales y las estaciones de trabajo y mainframes se fue cerrando. 

Hacia principios de los 1990, la mayor parte de las computadoras de ar- 
quitecturas alternativas fueron cediendo a las presiones del mercado, y hacia 
mediados de la decada solo quedaban dos arquitecturas principales: la deriva- 
da de IBM y la derivada de la Apple Macintosh. 

Los sistemas operativos primarios para ambas plataformas fueron respon- 
diendo a las nuevas caracteristicas del hardware: en las IBM, la presencia de 
Microsoft Windows (originalmente un entorno operativo desde su primera edi- 
cion en 1985, evolucionando hacia un sistema operativo completo ejecutando 
sobre una base de MS-DOS en 1995) se fue haciendo prevalente hasta ser la 
norma. Windows paso de ser un sistema meramente de aplicaciones propias y 
que operaba unicamente por reemplazo de aplicacion activa a ser un sistema 
de multitarea cooperativa y, finalmente un sistema que requeria proteccion en 
hardware (80386) e implementaba multitarea apropiativa. 

A partir del 2003, el niicleo de Windows en mas amplio uso fue reempla- 
zado por un desarroUo hecho de inicio como un sistema operativo completo 
y ya no como un programa bajo MS-DOS: el niicleo de nueva tecnologia (Win- 
dows NT), que, sin romper compatibilidad con los APIs historicos de Windows, 
ofrecio mucho mayor estabilidad. 

Por el lado de Apple, la evolucion fue muy en paralelo: ante un sistema 
ya agotado y obsoleto, el MacOS 9, en 2001 anuncio una nueva version de su 
sistema operativo que fue en realidad un relanzamiento completo: MacOS X es 
un sistema basado en un nucleo Unix BSD, sobre el microkernel Mach. 

Y otro importante jugador que entro en escena durante los anos noventa fue 
el software libre, por medio de varias implementaciones distintas de sistemas 
tipo Unix, principalmente, Linux y los *BSD (FreeBSD, NetBSD, OpenBSD). Es- 
tos sistemas implementaron, colaborativamente y a escala mundial, software 
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compatible tanto con las PC como con el que se ejecutaba en las estaciones de 
trabajo a gran escala, con alta confiabilidad, y cerrando por fin la divergencia 
del arbol del desarroUo de la computacion enfierros grandes yfierros chicos. 

Al dia de hoy, la arquitectura derivada de Intel (y la PC) es el claro ganador 
de este proceso de 35 anos, habiendo conquistado casi la totalidad de los casos 
de uso, incluso las maquinas Apple. Hoy en dia, la arquitectura Intel ejecuta 
desde subportatiles hasta supercomputadoras y centros de datos; el sistema 
operativo especifico varia segun el uso, yendo mayoritariamente hacia Win- 
dows, con los diferentes Unixes concentrados en los equipos servidores. 

En el frente de los dispositivos embebidos (las computadoras mas pequenas, 
desde microcontroladores hasta telefonos y tabletas), la norma es la arquitec- 
tura ARM, tambien bajo versiones especificas de sistemas operativos Unix y 
Windows (en ese orden). 

1.5. Dispositivos moviles 

En los ultunos anos, buena parte del desarroUo en el mundo del computo se 
ha volcado hacia el modelo de computo representado, genericamente, por los 
dispositivos moviles. Dado el interes que estas plataformas han despertado, se 
toma necesario abordar el tema, aunque sea mas para anotar similitudes que 
diferencias con el resto de los equipos de computo. Para hacer esto, sin embar- 
go, es necesario primero abordar la definicion: ^en que consiste un dispositivo 
movil, cuales son los llmites de su definicion, que fronteras se le pueden definir? 

Es diflcil encontrar llmites claros y duros para lo que este concepto abarca; 
en el transcurso de esta seccion se abordan las caracteristicas de las compu- 
tadoras disenadas no solo en el nivel del hardware, sino de interfaz usuario, 
para que su propietario las cargue consigo y las convierta en un asistente para 
sus actividades cotidianas, para la organizacion de su vida diaria. Partiendo de 
esta definicion se tiene que un teUfono inteligente sera tratado como dispositivo 
movil, pero una computadora portatil no, puesto que su interfaz es la misma 
de ima computadora estandar. 

Claro, esta definicion -indudablemente rapida e imperfecta- deja una gran 
area gris, y permite cierta ambigiiedad. Por ejemplo, las mas recientes versio- 
nes de algunos entomos de usuario (notablemente, la interfaz primaria de Win- 
dows 8, o los entomos GNOME y Unity de Linux) buscan unificar la experiencia, 
incorporando conceptos del multitouch a los escritorios y acercando los casos 
de uso. Tomense, pues, estos lineamientos como meramente indicativos. 

1.5.1. Resefia historica 

Tener una plataforma de computo movil ha sido uno de los anhelos mas 
reiterados del computo; ya en 1975, antes de la aparicion de todos los sistemas 
resenados en la seccion 1.4 (a excepcion de la Altair 8800) IBM lanzo al mercado 
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su primer computadora portatil: La IBM 5100, de 25 Kg de peso y con una pan- 
talla de 5 pulgadas (equivalente a un telefono celular grande del dia de hoy). 
Esta computadora tuvo un exito muy limitado en buena medida por su pre- 
cio: 9 000 dolares en su configuracion mas basica la dejaban claramente fuera 
del alcance del mercado de los entusiastas de la epoca, y la incomodidad de 
su pequena pantalla llevo al entorno corporativo a preferir seguir usando las 
minicomputadoras con terminales estandar para la epoca. 

Este mercado tambien vio una importante convergencia, en este caso desde 
abajo: la miniautrizacion vivida en la decada de los setenta fue, a fin de cuentas, 
iniciada por el CPU Intel 4004, disefiado expresamente para las calculadoras Bu- 
sicom. Durante esa epoca nacieron las calculadoras porta tiles. Estas comenza- 
ron implementando unicamente las operaciones aritmeticas basicas, pero con 
el paso del tiempo aparecieron las calculadoras cientificas, incluyendo operacio- 
nes trigonometricas. En 1974, Hewlett-Packard lanzo al mercado la HP-65 la 
primer calculadora de bolsillo plenamente programable. 

Para 1984, ya ante la franca popularizacion de las aplicaciones ofimaticas, 
la empresa britanica Psion lanzo la Psion Organiser, que se anunciaba como la 
primer computadora de bolsillo practica del mundo: era vendida con reloj, cal- 
culadora, una base de datos sencilla, y cartuchos de expansion con aplicaciones 
ejemplo (ciencia, matematicas y finanzas), ademas de un entorno de programa- 
cion para que el usuario desarrollara sus propias aplicaciones. 



Figura 1.6: Psion Organiser, anunciada como la primer computadora de bolsillo practica 
del mundo en 1984. En la imagen, un dispositivo de su segunda generacion (imagen 
de la Wikipedia: Psion Organiser). 



El hardware del Organiser original era, claro esta, muy limitado. Con solo 4 
KB de ROM y 2 KB de memoria no inclula un sistema operativo, y el lenguaje de 
programacion disponible al usuario era meramente un ensamblador No tener 
un sistema operativo significa que, en vez de hacer las llamadas al sistema nece- 
sarias para realizar transferencias (como se vera en la secc. 2.7 y en el cap. 7), el 
programador tenia que avanzar y transferir hyte por byte. Dos afios mas tarde, 
la segunda generacion del Organiser salio al mercado con un sistema operativo 
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monotarea y mucho mayor espacio de almacenamiento. Varias generaciones 
mas tarde, este sistema operative es el que hacia 1998 se convirtio en Symhian, 
que fuera el dominante del mercado de celulares durante la mayor parte de la 
decada del 2000. 




Figura 1.7: Sharp ZQ-770, diseno bajo uno de los formatos de PDA (Asistente Per- 
sonal Digital) mas popularizados de la decada de los noventa (imagen de la Wiki- 
pedia: Sharp Wizard). 

Siguiendo los pasos del Organiser, muchas otras empresas fueron creando 
pequeiios equipos con aproximadamente la misma funcionalidad basica (lis- 
ta de contactos, notas y agenda) e interfaz usuario, definiendo el termino de 
Asistente Digital Personal {Personal Digital Assistant, PDA). Hubo diferentes hitos 
durante la decada de los noventa, aunque destaca particularmente la platafor- 
ma Palm. Esta fue la primera plataforma con exito al incorporar una interfaz 
usuario tactil con escritura basada en reconocimiento de la letra (que era traza- 
da por medio de una pluma especial, o stylus, en la pantalla). 

El siguiente paso natural fue unir la funcionalidad del cada vez mas popu- 
lar telefono celular con la del PDA. Ya desde 1996 se comercializaron equipos 
ofreciendo la funcionalidad integrada, y el termino smartphone {telefono inteli- 
gente) se empleo por primera vez en 1998. Como se vera en la seccion 1.5.2, el 
reto de mantener la sefializacion estable significo que muchos de estos telefo- 
nos resultaban en una suerte de Frankenstein, con dos personalidades claramente 
diferenciadas. 

En el ano 2007, Apple presento su hoy iconico iPhone. Desde un punto de 
vista tecnico, la principal rnnovacion de este equipo fue una nueva interfaz 
grafica denominada multitouch {multitoque), que permite al usuario interactuar 
directamente con sus dedos (por medio de toques combinados o gestos y ya no 
requiriendo de un stylus) e incluso de la inclinacion del dispositivo. Y si bien el 
telefono mismo no represento un salto en las capacidades del hardware, Apple 
logro disenar una interfaz innovadora -como ya lo habla hecho en 1984 con la 
Macintosh- que se convirtio rapidamente en estandar para todo un mercado. 

Hasta este punto, practicamente la totalidad de dispositivos en el segmento 
reconocido como movil eran reconocibles por su tamano: casi todos los disposi- 
tivos mencionados en esta seccion estan hechos para caber en el bolsillo de una 
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Figura 1.8: El iPhone, de Apple, introdujo la primera interfaz usuario multitouch y 
detono la popularidad de los telefonos inteligentes — y con ello, del computo movil 
(imagen de la Wikipedia: iPhone 2). 

camisa. Sin embargo, a este segmento deben agregarse las tabletas. La historia 
de su desarrollo y adopcion se parecen a la aqui presentada respecto a la inter- 
faz de los telefonos inteligentes (e incluso, llevada mas al extremo): Es posible 
encontrar antecedentes desde 1915,^ numerosas descripciones literarias en la 
ciencia ficcion a lo largo del siglo XX, y varias implementaciones funcionales 
desde inicios de la decada de los noventa. Sin embargo, las tabletas parecieron 
por largos anos estar destinadas a nunca conquistar al mercado, hasta el ano 
2010, en que Apple lanzo un equipo con la misma interfaz de su iPhone pero 
del tamafio de una computadora portatil estandar. 

Todos los sistemas disponibles hoy en dia, claro esta, tienen muchlsima ma- 
yor complejidad que la del Psion Organizer, y hay varias familias de sistemas 
operativos de uso frecuente; se describiran a continuacion, y muy a grandes 
rasgos, solo algunos de los sistemas en uso. En la presente seccion se enume- 
ran linicamente con su informacion general, y en la siguiente se mencionan 
algunas de sus caracterlsticas tecnicas. 

iOS El sistema operativo de Apple, y disenado exclusivamente para el hard- 
ware producido por dicha companla. Fue el primero en implementar la 
interfaz usuario multitouch y, en buena medida, se puede ver como el 
responsable de la explosion y universalizacion en el uso de dispositivos 
moviles. Al igual que el sistema operativo que emplean para sus equipos 
de escritorio, MacOS X, ioS esta basado en el niicleo Darwin, derivado de 
FreeBSD, un sistema libre tipo Unix. 

Android Disenado por la companla Google, basa la mayor parte de su opera- 
cion en software libre (un nucleo Linux, maquina virtual Java, y muchas 
de las bibliotecas de sistema comunes en sistemas Linux), agregando una 
capa de servicios propietarios. La estrategia de Google ha sido inversa 



^El registro de patente 1 117 184 de los Estados Unidos se refiere a una maquina para reconocer 
los caracteres escritos en una hoja 
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a la de Apple: en vez de fabricar sus propios dispositivos, otorga licen- 
cias para el uso de este sistema operative a practicamente todos los fa- 
bricantes de hardware, con lo que la amplia mayoria de los modelos de 
telefonos inteligentes y tabletas corren sobre Android. 

Windows Phone Microsoft ofrece una version de su sistema operative, com- 
patible a nivel API con el Windows de escritorio, pero compilado para 
procesador arm. Este sistema operative no ha logrado conquistar gran 
popularidad, en claro contraste con su dominacion en el compute tradi- 
cional de escritorio; el principal fabricante que vende equipos con Win- 
dows Phone es Nokia (que, despues de haber side la compania Ifder en 
telefenia, fue adquirida per Microsoft mismo). 

Symbian Si bien este sistema operative ya esta declarado come oficialmente 
muerte, su efecto en el desarrollo temprano del segmento fue fimdamen- 
tal, y no puede ser ignorado. Symbian fue la plataforma principal para 
Nokia en su epoca de gloria, asi como para muchos otros fabricantes. 
Casi todas las empresas que antiguamente operaban con Symbian han 
mudado su oferta a sistemas Android. 

Firefox OS La fundacion Mozilla, responsable del navegador Firefox (y here- 
dera del historico Netscape) esta intentando entrar al mercado mobil con 
este sistema, basado (al igual que Android) en el nucleo de Linux, pero 
orientado a ofrecer una interfaz de programacion siguiendo completa- 
mente los estandares y lenguajes para uso en la Web. Esta plataforma 
hace una apuesta mucho mas agresiva que las demas a un esquema de 
conexion permanente a la red de datos. 

1.5.2. Caracteristicas dif erenciadoras 

Resultara claro, a partir de los sistemas recien presentados, asf como la gran 
mayoria de los sistemas operatives empleados para dispositivos moviles, que 
la diferenciacion entre el segmento movil y el compute tradicional no esta en el 
sistema operative mismo, sine en capas superiores. Sin embargo, la diferencia 
va mucho mas alia de un cambio en la interfaz usuario; las caracteristicas de 
estes dispositivos indudablemente determinan cuestiones de fondo. A conti- 
nuacion, se exponen algunas de las caracteristicas mas notorias. 

Almacenamiento en estado solido 

La primer caracteristica notoria al manipular un telefono o una tableta es 
que ya no se hace con la nocion de fragilidad que siempre acompano al compu- 
to: los discos duros son dispositivos de altisima precision mecanica, y un pe- 
queno golpe puede significar su averia absoluta y definitiva. Los dispositivos 
moviles operan con almacenamiento en estado solido, esto es, en componentes 
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electronicos sin partes moviles. La evolucion y las caracterfsticas del almacena- 
miento en estado solido seran cubiertas en la seccion C.1.2. 

Al estar principahnente orientados a este medio de almacenamiento, en H- 
neas generales, los sistemas operatives moviles no emplean memoria virtiial, 
tema que sera cubierto en la seccion 5.7. No pueden, por tanto, mantener en 
ejecucion programas que excedan del espacio real de memoria con que cuente 
el sistema — y esto conlleva importantes consideraciones de diseno. 

Multitarea, pero monocontexto 

La forma de uso de las computadoras dio un salto cualitativo, tanto en el 
mundo corporativo hacia la decada de los sesenta como en el personal hacia 
inicios de los noventa, con la introduccion de sistemas con capacidades mul- 
titarea (vease la seccion 1.3.3). Los usuarios se han acostumbrado a que sus 
equipos hagan muchas cosas (aparentemente) al mismo tiempo, y es ya una ex- 
pectativa comun el poder tener abierta una cantidad arbitraria, a veces incluso 
excesiva, de programas en ejecucion, al grado de que practicamente los usua- 
rios promedio del computo reconocen perfectamente la hiperpaginacion (que 
sera descrita en la seccion 5.20) por sus smtomas. 

La popularizacion del computo movil llevo, sin embargo, a una fuerte re- 
duccion en las expectativas de multitarea. Esto principalmente por dos razones; 
la primera es que, al carecer los dispositivos moviles de memoria virtual, la me- 
moria disponible se vuelve nuevamente un bien escaso, y el sistema operative 
se ve obligado a limitar al mimero de procesos interactivos en ejecucion.^ 

Esta distincion tambien puede explicarse por el modelo de uso de estos 
dispositivos: comparadas con las pantallas de equipos de escritorio, donde las 
pantallas mas frecuentemente utilizadas son de 17 pulgadas,^ los telefonos van 
en general de las 3.5 a las 5 pulgadas. Una interfaz usuario disenada para un 
tipo de pantalla no puede resultar satisfactoria en el otro. 

Las interfaces usuario empleadas por los sistemas moviles abandonan el 
modelo de interaccion wimp presentado en la seccion 1.4.4, asi como la metdfora 
del escritorio, para volver a la de un solo programa visible en todo momento. 

Al buscar satisfacer las necesidades de un mercado mucho mas amplio y 
mucho menos versado en los detalles del computo, todas estas interfaces con- 
Uevan importante simplificaciones. Una de las mas notorias es que los usuarios 

^Formalmente, no es el sistema operative mismo, sino que el software de sistema, que monitorea 
el uso y rendimiento, y toma decisiones a mas alto nivel. En todas las plataformas mencionadas, 
hay una fuerte distincion entre los programas que operan como sewicios y se mantienen activos en 
el fondo y aquellos que operan en primer piano, con interfaz grdfica e interacci6n directa con el 
usuario. 

^La medida m^s habitual para las pantallas indica las pulgadas que miden en diagonal. Tras 
muchos aftos en que la relacion de dimension vertical contra horizontal o aspecto de las pantallas 
fuera de 3:4, este formato se ha ido reemplazando por el de 9:16, por lo que la medida en pulgadas 
por si sola ahora Ueva ima carga de ambigiiedad. 
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ya no solicitan la finalizacion de un programa: los programas van siendo lan- 
zados (y utilizados uno por uno), y si cahen en memoria son mantenidos abiertos 
para evitar las demoras de volver a inicializar. El sistema define politicas por 
medio de las cuales estos programas seran finalizados y evacuados de la memo- 
ria al llegar a determinados umbrales. 

Consumo electrico 

Una de las areas en que mas visible ha sido el desarroUo cualitativo durante 
los liltimos anos es la optimizadon del consumo electrico de los equipos de 
computo. Y si bien no puede negarse la unportancia del ahorro electrico en las 
oficinas y centros de datos, donde el trabajo diario cada vez depende mas del 
computo, tampoco puede ignorarse la importancia de popularizacion de las 
computadoras porta tiles. Y agregando algunos patrones particulares a estos 
dispositivos, la popularizacion del computo movil ha Uevado a una verdadera 
revolucion en este aspecto. 

El ahorro del consumo electrico tiene dos principales vertientes: por un la- 
do, el desarrollo de hardware mas eficiente energeticamente, con independen- 
cia del modo en que opere y, por el otro, la creacion de mecanismos por medio 
de los cuales un equipo de computo pueda detectar cambios en el patron de 
actividad (o el operador pueda indicarle un cambio en la respuesta esperada), 
y este reaccione reduciendo su demanda (lo cual tipicamente se obtiene redu- 
ciendo la velocidad de ciertos componentes del equipo). 

El primer esquema de ahorro de energfa con amplio soporte, tanto por parte 
de hardware de diversos fabricantes, como de practicamente todos los sistemas 
operativos ampliamente utilizado, fue apm (Advanced Power Management, Ges- 
tion Avanzada de la Energfa). Pasado cierto tiempo, fue reemplazado por ACPI 
(Advanced Configuration and Power Interface, Interfaz Avanzada de Configura- 
cion y Energfa); la principal diferencia entre ambas es que, mientras que bajo 
APM los diferentes niveles de energfa se implementaban en el firmware de la 
computadora o cada uno de sus dispositivos, en ACPI la responsabilidad recae 
en el sistema operativo; esto brinda mucho mayor flexibilidad a la implemen- 
tacion, a cambio de una mayor complejidad para los desarrolladores. 

Pero la verdadera diferencia en el tema que esta seccion aborda es la fre- 
cuencia de los cambios de estado: un servidor o computadora de escritorio 
tiene solo un evento constante (el ajuste de frecuencia del procesador depen- 
diendo de la carga, potencialmente hasta decenas de veces por segundo); una 
computadora portatil debe adoptar diferentes perfiles dependiendo de si esta 
conectada a la red electrica u operando por baterfa, o si tiene la tapa (pantalla) 
abierta o cerrada. Los usuarios de computadoras portatiles tipicamente buscan 
trabajar conectados a la red electrica tanto como sea posible, dado que es vox 
populi que esto mejorara la vida litil de su baterfa. Y si bien estos cambios de 
entomo se presentan (y guardan una innegable complejidad), su ocuxrencia es 
muy baja. 
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En el computo movil, los eventos son muchos y muy distintos. En primer 
lugar, los dispositivos moviles operan bajo una filosofia de siempre encendido: 
A pesar de que el usuario no este atento a su dispositivo, este tiene que estar 
encendido y al pendiente del entorno — algunos ejemplos casi obvios: 

■ En caso de entrar una Uamada telefonica, tiene que responder inmediata- 

mente alertando al usuario. La interfaz usuario del telefono puede pare- 
cer apagada, pero su logica (y en particular su senalizacion a las distintas 
redes a las que esta conectado) se mantiene activa. 

■ El equipo tiene que estar siempre alerta a las condiciones cambiantes de 
red (tanto telefonica como de datos), midiendo la senal de las antenas ce- 
lulares mas cercanas; mantenerse asociado a una antena remota reqmere 
mas energia que a una cercana. 

■ Dado que estos equipos estan disenados para moverse junto con el usua- 
rio, convirtiendose en un asistente o una extension para sus actividades 
diarias, optimizan su funcionamiento para operar como norma desde su 
bateria, no conectados a la red electrica. Valga en este caso la compara- 
cion: un telefono que brinde menos de un dia de operacion autonoma se- 
ria sin duda evaluado como extiemadamente incomodo e impractico, en 
tanto una computadora portatil se considera muy eficiente si permite la 
operacion autonoma por seis horas. 

El ahorro de energia que permite estos patrones de uso no solo se debe al 
hardware cada vez mas eficiente que emplean los dispositivos moviles, sino 
que a una programacion de las aplicaciones en que los desarrolladores expHci- 
tamente buscan patrones eficientes, facil suspension, y minimizando la necesi- 
dad de despertar al hardware. 

Entorno cambiante 

Los centros de datos, las computadoras de escritorio, e incluso las portatiles 
tienen una forma de operacion bastante estable: durante el transcurso de una 
sesion de trabajo (e incluso durante la vida entera del equipo, en el caso de los 
servidores) su vision del mundo no esta sujeta a mayores cambios. Un usuario 
puede mantener por largos periodos su configuracion de consumo energetico. Las 
interfaces y direcciones de red son tipicamente estables, y si hubiera un proble- 
ma de senal, la reparacion o reubicacion se haria en la infraestructura de red, 
no en el equipo cliente. El formato de la pantalla, claro esta, es tambien estable. 

Uno de los cambios mas dificiles de implementar en el software del sistema 
fue precisamente el de brindar la plasticidad necesaria en estos diferentes as- 
pectos: el dispositivo movil debe ser mas energico en sus cambios de perfil de 
energia, respondiendo a un entorno cambiante. Puede aumentar o disminuir 
la luminosidad de la pantalla dependiendo de la luminosidad circundante, o 
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desactivar determinada funcionalidad si esta ya en niveles criticos de carga. 
Con respecto a la red, debe poder aprovechar las conexiones fugaces mientras 
el usuario se desplaza, iniciando eventos como el de sincronizacidn. Y encar- 
gandose de detener (tan limpiamente como sea posible) los procesos que van 
dejando de responder. Por ultimo, claro, la interfaz usuario: los dispositivos 
moviles no tienen una orientacion # linica natural, como si la tienen las compu- 
tadoras. Las interfaces usuario deben pensarse para que se puedan reconfigurar 
agilmente ante la rotacion de la pantalla. 

El jardin amurallado 

Una consecuencia indirecta (y no tecnica) del nacimiento de las platafor- 
mas moviles es la popularizacion de ujn modelo de distribucion de software 
conocido como jardin amurallado o, lo que es lo mismo, ima plataforma cerrada. 

Partiendo de que los telefonos inteligentes, en un primer momento, y las 
tabletas y dispositivos sunilares posteriormente, buscan satisfacer un mercado 
mucho mayor al de los entusiastas del computo,'* Apple anuncio en julio del 
2008 (un ano despues del lanzamiento del iPhone) su tienda de aplicaciones o 
app store. La peculiaridad de esta con relacion al modelo de computo que ha 
imperado historicamente es que, si bien cualquier desarrollador puede crear 
una aplicacion y enviarla, Apple se reserva el derecho de aprobarla, o elimi- 
narla en cualquier momento. Esto es, este modelo le permite erigirse en juez, 
determinando que puede o no ejecutar ujn. usuario. 

Este mismo modelo fue adoptado por Google para su sistema Android, en 
un principio bajo el nombre Mercado Android, y desde el 2012 como Google Play. 
Microsoft hizo lo propio con su Windows Phone Store. 

Este modelo de autorizacion y distribucion de software, sin embargo, rom- 
pe con lo que Jonathan Zittrain (2008) define como la generatividad de los equi- 
pos de computo y de la red en general. Para ampliar el debate en este entido, 
el libro de Zittrain se ha vuelto referenda obligada, y esta disponible completo 
en Imea. 

1.6. Seguridad informatica 

No puede perderse de vista la importancia de la seguridad informatica. Pue- 
de verse el efecto de este concepto en practicamente todos los componentes 
que conforman a un sistema operativo. Para no ir mas lejos, las funciones prin- 
cipals presentadas en la seccion 1.2 cruzan necesariamente por criterios de 
seguridad. Algunas consideraciones podrian ser, por ejemplo: 

*Y tambien como respuesta a que algunos usuarios encontraron c6mo romper la protecci6n y 
poder desarroUar e instalar aplicaciones extraoflciales en esta plataforma, disenada originalmente 
para s61o correr software de Apple. 
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Abstraccion El sistema operativo debe asegurarse no solo de proveer las abs- 
tracciones necesarias, sino tambien de que ninguno de sus usuarios pue- 
da evadir dichas abstracciones. Per ejemplo, el que un usuario tenga de- 
recho a modificar un archivo que este alojado en determinada unidad de 
disco, no debe poder escribir directamente al disco; su acceso debe estar 
limitado a la interfaz que el sistema le ofrece. 

Administracion de recursos Si el sistema operativo definio determinada po- 
litica de asignacion de recvirsos, debe evitar que el usuario exceda las 
asignaciones aceptables, sea en el curso de su uso normal, o incluso ante 
patrones de uso oportunista — Esto es, conociendo los mecanismos y po- 
Hticas, un usuario no debe poder lograr que el sistema le permite el uso 
por encima de lo definido. 

Aislamiento Si el sistema operativo ofrece separacion entre los datos, procesos 
y recursos de sus distintos usuarios, ninguno de ellos debe -accidental o 
intencionalmente- tener acceso a la informacion que otro haya marca- 
do como privada. Ademas, retomando el inciso anterior, ninguno de los 
usuarios debe poder lograr que, por sus acciones, el sistema penalice a 
otros mas alia de lo que la poHtica de asignacion de recursos estipule. 

Claro esta, estos tres incisos son presentados unicamente como ejemplo; a 
lo largo de la obra se presentaran varios casos relacionados con los distintos 
temas que se abordan. 

Naturalmente, todo problema que se plantee relativo a la seguridad infor- 
matica puede ser abordado (por lo menos) desde dos puntos de vista anta- 
gonistas: el de la proteccion, que busca definir y proteger los aspectos en que 
intervenga la seguridad para un problema dado, y el del ataque, que busca las 
debilidades o vulnerabilidades en determinada implementacion de un esquema 
de segiiridad que permitan, a quien las conozca, violar los llmites que el admi- 
nistrador del sistema busca imponerle. Y claro, si bien el tipo de analisis para 
estos puntos de vista es muy distinto, comprender ambos resulta no unicamen- 
te legltimo sino necesario para una formacion profesional completa. 

Todas las areas que aborda la presente obra tienen aspectos que pueden 
analizarse desde la seguridad informatica, y mas que dedicar un capftulo en 
particular a este tema, la apuesta es por abordar la seguridad de forma trans- 
versal. 

1.6.1. Codigo malicioso 

Los sistemas operativos, al igual que todo programa de computo, presentan 
imperfecciones, errores u omisiones, tanto en su diseno como en su implemen- 
tacion. El codigo malicioso (tambien conocido como malware) consiste en progra- 
mas disenados para aprovechar dichas vulnerabilidades para adquirir privilegios 
de ejecucion o acceso a datos que de otro modo no habrian logrado. 
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Si la vulnerabilidad que aprovecha el codigo malicioso es resultado de un 
error en la implementacion, el desarroUador del sistema operativo tipicamente 
podra corregirla y poner esta correccion (coloquialmente denominada parche) a 
disposicion de los usuarios; en los sistemas operatives modernos, la instalacion 
de estas correcciones se efectiia de forma automatizada. Por otro lado, si la 
vulnerabilidad es consecuencia de una debilidad en el diseno, su correccion 
puede ser mucho mas compleja, incluso puede ser imposible de resolver, como 
el caso presentado en la seccion 5.8.1.^ 

Cabe mencionar que una gran cantidad de codigo malicioso ataca a una 
capa particiilarmente debil de todo sistema de computo: al usuario. Un aspec- 
to frecuente (y de muy dificil solucion) de estos programas es que enganan al 
usuario presentandose como codigo legltimo, y si este reacciona como el codi- 
go malicioso busca, le permitira la ejecucion en el sistema con sus privilegios. 

El codigo malicioso tiende a agruparse y clasificarse de acuerdo a su com- 
portamiento, particularmente de cara al usuario: virus, gusanos, caballos de troy a, 
exploits, y muchos mas. Sin embargo, y dado que sus diferencias radican par- 
ticularmente en sus multiples comportamientos ante el usuario o como programa 
en ejecucion (y se comportan en Imeas generales del mismo modo ante el siste- 
ma operativo), se determine que entrar en detalles al respecto resultaria fuera 
del ambito de la presente obra. 

1.7. Organizacion de los sistemas operatives 

la complejidad del tema de los sistemas operativos requiere que se haga de 
■una forma modiilar. En este texto no se busca ensenar como se usa mv determi- 
nado sistema operativo, ni siquiera comparar el uso de uno con otro (fuera de 
hacerlo con fines de explicar diferentes implementaciones). 

En el nivel que se estudiara, un sistema operativo es mas bien \m gran pro- 
grama, que ejecuta otros programas y les provee un conjunto de interfaces para 
que puedan aprovechar los recursos de computo. Hay dos formas primarias de 
organizacion interna del sistema operativo: los sistemas monoHticos y los sis- 
temas microkernel. Y si bien no se puede marcar ima Imea clara a rajatabla 
que indique en que clasificiacion cae cada sistema, no es dificil encontrar lineas 
bases. 

Monolfticos La mayor parte de los sistemas operativos historicamente han si- 
do monoHticos: esto significa que hay un solo proceso privilegiado (justa- 

^El caso de los desbordamientos de buffer no se debe directamente al diseno de uno de los siste- 
mas operativos en particular. Su existencia, asi como su presencia generalizada por mas de 40 anos 
despues de haberse descrito, puede explicarse por la imposibilidad de resolverse este problema 
sin el consimio reiterado de recursos de computo con operaciones demasiado frecuentes. En es- 
te caso en particular, el desbordamiento puede evitarse linicamente usando lenguajes con gesti6n 
automStica de memoria, mucho m^s lentos que los lenguajes de bajo nivel, o concientizando a los 
desarroUadores de las prdcticas responsables de programaci6n. 
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mente el sistema operativo) que opera en modo supervisor, y dentro del 
cual se encuentran todas las rutinas para las diversas tareas que realiza el 
sistema operativo. 
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Figura 1.9: Esquematizacion de los componentes en un sistema monolitico. 

Microkernel El nucleo del sistema operativo se mantiene en el mlnimo posi- 
ble de fimcionalidad, descargando en procesos especiales sin privilegios las 
tareas que implementan el acceso a dispositivos y las diversas politicas 
de uso del sistema. 
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Figura 1.10: Esquematizacion de los componentes en un sistema microkernel. 



La principal ventaja de disenar un sistema siguiendo im esquema monoliti- 
co es la simplificacion de una gran cantidad de mecanismos de comimicacion, 
que lleva a una mayor velocidad de ejecucion (al requerir menos cambios de 
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contexto para cualquier operacion realizada). Ademas, al manejarse la comu- 
nicacion directa como paso de estructuras en memoria, el mayor acoplamiento 
permite mas flexibilidad al adecuarse para nuevos requisites (al no tener que 
modificar no solo al niicleo y a los procesos especiales, srno tambien la rnterfaz 
publica entre ellos). 

Por otro lado, los sistemas microkernel siguen esquemas logicos mas lim- 
pios, permiten implementaciones mas elegantes y facilitan la comprension por 
separado de cada una de sus piezas. Pueden auto-repararse con mayor facilidad, 
dado que en caso de fallar uno de los componentes (por mas que parezca ser 
de muy bajo nivel), el nucleo puede reiniciarlo o incluso reemplazarlo. 

Sistemas con concepciones hibridas No se puede hablar de concepciones uni- 
cas ni de verdades absolutas. A lo largo del libro se veran ejemplos de 
concepciones hibridas en este sentido: sistemas que son mayormente mono- 
llticos pero que manejan algunos procesos que parecerlan centrales me- 
diante de procesos de nivel usuario como los microkernel (por ejemplo, 
los sistemas de archivos en espacio de usuario, FUSE, en Linux). 
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Figura 1.11: Esquematizacion de los componentes en un sistema hibrido. 



1.8. Ejercicios 

1.8.1. Preguntas de autoevaluacion 

1. ^En que se diferencia la multitarea apropiativa de la cooper ativa? Para 
todas las opciones, lease: "A diferencia de la multitarea cooperativa, la 
apropiativa. . . " (Seleccione al menos una respuesta.) 

a) Es inmime a que im calculo demasiado largo o un ciclo rnfinito dejen 
a la computadora efectivamente congelada. 

b) Es la mas utilizada hoy en dla. 

c) Ocurre solo cuando el proceso hace una llamada al sistema. 
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d) Se emplea principalmente en sistemas multiusuario. 

e) Requiere apoyo de hardware. 

2. Un sistema operative ofrece una serie de recursos o caracterlsticas prin- 
cipales, tanto a sus usuarios como a sus programadores. Estos pueden 
agruparse en aislamiento, administracion de recursos y abstraccion. 

De las siguientes afirmaciones, ^cual responde a cada uno de dichos con- 
ceptos, y cual no corresponde a \ma funcion del sistema operative? 

■ Instrumentar poHticas que repartan la atencion del sistema de forma 
efectiva y acorde a las necesidades establecidas entre los diferentes 
procesos o usuarios. 

■ Cada proceso y cada usuario no tendran que preocuparse por otros 
que esten usando el mismo sistema; ideaknente, su experiencia sera 
la misma que si el sistema estuviera exclusivamente dedicado a su 
atencion. Requiere que el sistema operative cuente con ayuda del 
hardware. 

■ Presentar una interfaz consistente al usuario (puede ser grafica o 
textual), eliminando las diferencias que provendrian de manejar dis- 
tintos tipos de hardware. 

■ Los programadores no deben tener que preocuparse de los deta- 
lles del acceso a hardware, o de la configuracion particular de una 
computadora. El programador debe poder enfocarse en resolver los 
problemas o necesidades particulares de sus usuarios. 

3. Algunos dispositivos requieren de bloqueo para garantizar a im progra- 
ma su acceso exclusive. ^Cuales de los siguientes entrarian en ese su- 
pueste? 

a) Teclade. 

b) Unidad de cinta. 

c) Discos. 

d) Impresera. 

4. Un pregrama tipicamente pasa per varias etapas en su ejecucion, algunas 
de las cuales estan limitadas por el procesador, mientras que las otras 
lo estan per la entrada/salida. Los componentes del sistema que estan 
ecupades en cada case sen distintes. 

^Que tipe de sistemas nacieren para respender a esta necesidad? 

5. Se presento que los sistemas microkernel se basan en la simplificacion de 
los mecanismos de comunicacion y un esquema mas claro de comunica- 
cion entre componentes. Sin embargo, los sistemas menelitices siempre 



1.8. EJERCICIOS 



41 



fueron mas simples de implementar, razon por la cual muchos sistemas 
microkernel se han reducido a ejercicios academicos. Explique esta ten- 
sion. 

6. De los sistemas operativos ampliamente utilizados que conozca, averigiie 
cuales son microkernel y cuales son monolfticos. 

7. Los sistemas operativos empleados para dispositivos moviles son los 
mismos que los que utilizan las computadoras personales, sin embargo, 
hay areas particulares, como la interfaz al usuario o el manejo de la ener- 
gia, que son claramente distintos: ^como puede verse la influencia en el 
sentido inverso? Esto es, ique tanto ha influido la popularizacion de los 
dispositivos moviles en el camino de los sistemas operativos en general? 

1.8.2. Lecturas relacionadas 

■ On building systems that will fail 

http: //dl. acm.org/citat ion. cfin?id=12 83 94 7 
Fernando J. Corbato (1990); ACM Turing award lectures 

■ A Brief History of Computer Operating Systems 

http : / /cs . go r don . edu/ courses/ cs 322 /lectures /history . html 
R. Bjork (2000); Gordon College 

■ Making EPERM friendlier 
http://lwn.net/Articles/532 771/ 

Michael Kerrisk (2013); Linux Weekly News: explica algunas de las limi- 
tantes de la semantica POSIX como la falta de granularidad en el reporte 
de mensajes de error (EPERM) y errno global por hilo. 

■ Biculturalism 

http : //www . joelonsof tware . com/ articles /Biculturalism. html 
Joel Spolsky (2003); Joel on Software 

■ The future of the Internet and how to stop it 
http : / / f utureof theinternet . org/ 

Jonathan Zittrain (2008); Yale University Press 



Capitulo 2 

Relacion con el hardware 



2.1. Introduccion 

Todos los sistemas de computo estan compuestos por al menos una unidad 
de proceso junto con dispositivos que permiten ingresar datos (teclado, mouse, 
microfono, etc.) y otros que permiten obtener resultados (pantalla, impresora, 
parlantes, etc.). Como se vio anteriormente, una de las funciones del sistema 
operativo es la de abstraer el hardware de la computadora y presentar al usua- 
rio una version unificada y simplificada de los dispositivos. En este capitulo 
se vera la relacion que mantiene el sistema operativo con el hardware, las fun- 
ciones que cumplen y algunas abstracciones comunes utilizadas en sistemas 
operativos modemos. 

2.2. Unidad de procesamiento 

Es la parte fundamental de todo sistema de computo. Esta es la encarga- 
da de ejecutar tanto los programas del usuario como el sistema operativo en 
SI mismo. La funciones del sistema operativo respecto a la imidad de procesa- 
miento son: 

Inicializacion Luego de ser cargado el sistema operativo debe realizar varias 
tareas de inicializacion como habilitar las interrupciones de hardware y 
software (excepciones y trampas), configiurar el sistema de memoria vir- 
tual (paginacion, segmentacion), etcetera. 

Atender las interrupciones y excepciones Como se vera mas adelante, la uni- 
dad de procesamiento puede encontrar una situacion que no puede re- 
solver por SI misma (una instruccion o direccion invalida, una division 
por cero, etc.), ante lo cual le pasa el control al sistema operativo para 
que este trate o resuelva la situacion. 
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Multiplexacion En un sistema multiproceso, el sistema operative es el encar- 
gado de administrar la unidad de procesamiento dando la ilusion a los 
procesos que estan ejecutando de forma exclusiva. 

2.2.1. Jerarquia de almacenamiento 

Las computadoras que siguen la arquitectura von Neumann, esto es, practi- 
camente la totalidad hoy en dia} podrian resumir su operacion general a ali- 
mentar a una unidad de proceso (CPU) con los datos e instrucciones aLmacenados 
en memoria, que pueden incluir Uamadas a servicio (y respuestas a eventos) 
originados en medios extemos. 

Una computadora von Neumann significa basicamente que es una compu- 
tadora de programa almacenado en la memoria primaria — esto es, se usa el mismo 
almacenamiento para el programa que esta siendo ejecutado y para sus datos, 
sirviendose de im registro especial para indicar al CPU cual es la direccion en 
memoria de la siguiente instruccion a ejecutar. 

La arquitectura von Neumann fue planteada, obviamente, sin considerar la 
posterior diferencia entre la velocidad que adquiriria el CPU y la memoria. En 
1977, John Backus presento al recibir el premio Turing un articulo describiendo 
el cuello de botella de von Neumann. Los procesadores son cada vez mas rapidos 
(se logro un aumento de 1 000 veces tanto entre 1975 y 2000 tan solo en el reloj 
del sistema), pero la memoria aumento su velocidad a un ritmo mucho menor; 
aproximadamente un factor de 50 para la tecnologia en un nivel costo-beneficio 
suficiente para usarse como memoria primaria. 

Una respuesta parcial a este problema es la creacion de ima jerarquia de al- 
macenamiento, yendo de una pequena area de memoria mucho mas cara pero 
extremadamente rapida y hasta un gran espacio de memoria muy economica, 
aunque mucho mas lenta, como lo ilustran la figura 2.1 y el cuadro 2.1. En par- 
ticular, la relacion entre las capas superiores esta administrada por hardware 
especializado de modo que su existencia resiilta transparente al programador. 

Ahora bien, aunque la relacion entre estos medios de almacenamiento pue- 
de parecer natural, para una computadora tiene una realidad completamente 
distinta: los registros son parte integral del procesador, y la memoria esta a so- 
lo un paso de distancia (el procesador puede referirse a ella directamente, de 
forma transparente, indicando la direccion desde un programa). Para efectos 
practices, el cache no se maneja expHcitcamente: el procesador no hace refe- 
renda directa a el, sino que es manejado por los controladores de acceso a me- 
moria. Y por ultimo, el acceso o modificacion de cualquier dato almacenado en 
disco requiere en primer termino de la transferencia a la memoria, y solamente 

^ Algunos argumentaran que muchas de las computadoras en uso hoy en dia siguen la arquitec- 
tura Harvard modificada, dado que empleando distintos bancos de memoria cach6, un procesador 
puede, tanto referirse a la siguiente instrucci6n, como iniciar ima transferencia de memoria prima- 
ria. Esta distinci6n no tiene mayor relevancia para este tema, la referenda se incluye linicamente 
por no Uevar a confusi6n. 
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Figura 2.1: Jerarquia de memoria entre diversos medios de almacenamiento. 



cuando esta haya finalizado, el llamado a las rutinas que son presentadas en la 
seccion 2.4, y analizadas en los capitulos 6 y 7. 

Como se vera, el sistema operative es el encargado de mantener la informa- 
cion almacenada en todos estos tipos de memoria de forma consistente, y de 
realizar las transferencias entre imas y otras. 



Registros 

La memoria mas rapida de la computadora son los registros, ubicados en 
cada uno de los nucleos de cada CPU. Las arquitecturas tipo RISC (Reduced 
Instruction Set Computer) solo permiten la ejecucion de instrucciones entre 
registros (excepto, claro, las de carga y almacenamiento a memoria prunaria). 

Los primeros CPU trabajaban con pocos registros, muchos de ellos de pro- 
posito especifico, se regian mas bien con una logica de registro acumulador. Por 
ejemplo, el MOS 6502 (en el cual se basaron las principales computadoras de 
ocho bits) tenia un acumulador de ocho bits (A), dos registros mdice de ocho 
bits (x e y), un registro de estado del procesador de ocho bits (P), un apuntador 
al stack de ocho bits (S), y mv apimtador al programa de 16 bits (PC). El otro 
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Cuadro 2.1: Velocidad y gestor de los principales niveles de memoria (Silberschatz, 
Galvin, Gagne; p.28). 
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gran procesador de su era, el Zilog z80, tenia 14 registros (tres de ocho bits y el 
resto de 16), pero solo uno era un acumulador de proposito general. 

El procesador Intel 8088, en el cual se baso la primer generacion de la arqui- 
tectura PC, ofrecia cuatro registros de uso casi general. En los ochenta comen- 
zaron a producirse los primeros procesadores tipo RISC, muchos de los cuales 
ofrecian 32 registros, todos ellos de proposito general. 

El compilador^ busca realizar muchas operaciones que deben ocurrir reite- 
radamente, donde la rapidez es fundamental, con sus operadores cargados en 
los registros. El estado del CPU a cada momento esta determinado por el con- 
tenido de los registros. El contenido de la memoria, obviamente, debe estar 
sincronizado con lo que ocurre dentro de este — pero el estado actual del CPU, 
lo que esta haciendo, las indicaciones respecto a las operaciones recien realiza- 
das que se deben entregar al programa en ejecucion, estan todas representadas 
en los registros. Se debe mantener esto en mente cuando posteriormente se ha- 
bla de todas las situaciones en que el flujo de ejecucion debe ser quitado de uxi 
proceso y entregado a otro. 

La relacion de la computadora y del sistema operativo con la memoria prin- 
cipal sera abordada en el capitulo 5. 

2.2.2. Interrupciones y excepciones 

La ejecucion de los procesos podrfa seguir siempre linealmente, atendiendo 
a las instrucciones de los programas tal como fueron escritas, pero en el mode- 
lo de uso de computo actual, eso no serviria de mucho: para que un proceso 
acepte interaccion, su ejecucion debe poder responder a los eventos que ocurran 



^A veces asistido por instrucciones expHticas por parte del programador, pero muchas veces 
como resultado del andlisis del c6digo. 
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Figura 2.2: Ejemplo de registros: Intel 8086/8088 (imagen de la Wikipedia: Intel 
8086 y 8088). 



alrededor del sistema. Y los eventos son manejados mediante las interrupciones 
y excepciones (o trampas). 

Cuando ocurre algiin evento que requiera la atencion del sistema operati- 
ve, el hardware encargado de procesarlo escribe directamente a una ubicacion 
predeterminada de memoria la naturaleza de la solicitud (el vector de interrup- 
cion) y, levantando una solicitud de interrupcion, detiene el proceso que estaba 
siendo ejecutado. El sistema operative entonces ejecuta su rutina de manejo de 
interrupciones (tipicamente comienza grabando el estado de los registros del 
CPU y otra informacion relativa al estado del proceso desplazado) y posterior- 
mente la atiende. 

Las interrupciones pueden organizarse por prioridades, de modo que una in- 
terrupcion de menor jerarquia no interrumpa a una mas importante, dado que 
las interrupciones muchas veces indican que hay datos disponibles en algiin 
buffer, el no atenderlas a tiempo podria llevar a la perdida de datos. 

Hay un niimero limitado de interrupciones definidas para cada arquitectu- 
ra, mucho mas limitado que el numero de dispositivos que tiene un equipo de 
computo actual. Las interrupciones son, por tanto, generadas por el controlador 
del canal en que son producidas. Si bien esto resuelve la escasez de interrup- 
ciones, dificulta su priorizacion -con canales de uso tan variado como el USB 
{Universal Serial Bus, Canal Serial Universal),^ una interrupcion puede indicar 
que hay desde un teclazo para ser leldo hasta un paquete de red esperando a ser 



^Algunas arquitecturas, particularmente de sistemas embebidos y por un criterio altamente 
econ6inico, est&i estructuradas tntegramente alrededor de un bus USB. 
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procesado- y si bien demorar la atencion al primero no llevaria a una perdida 
notable de informacion, no atender el paquete de red si. 

El sistema operativo puede elegir ignorar (enmascarar) ciertas interrupcio- 
nes, pero hay algunas que son no enmascarables. 

Se hace la distincion entre interrupciones y excepciones segiin su origen: 
una interrupdon es generada per causas externas al sistema (un dispositive 
requiere atencion), mientras que una excepcion es un evento generado por un 
proceso (una condicion en el proceso que requiere la intervencion del sistema 
operativo). Si bien hay distinciones sutiles entre interrupciones, trampas y ex- 
cepciones, en el nivel de discusion que se abordara basta con esta distincion. 

Los eventos pueden ser, como ya se menciono, indicadores de que hay al- 
giin dispositivo requiriendo atencion, pero pueden tambien provenir del mis- 
mo sistema, como una alarma o temporizador (que se emplea para obligar a to- 
do programa a entregar el control en un sistema multitareas) o indicando una 
condicion de error (por ejemplo, una division sobre cero o un error leyendo de 
disco). 

Las ftinciones del sistema operativo respecto a las interrupciones son: 

Administrar el hardware manejador de interrupciones Esto incluye el enmas- 
carado y desenmascarado de las interrupciones, asignar y configurar in- 
terrupciones a cada dispositivo, notificar al manejador cuando la inte- 
rrupdon ya ha sido atendida, etcetera. 

Abstraer las interrupciones El sistema operativo oculta a los programas de 
usuario que ocurren interrupciones de hardware ya que estas son depen- 
dientes de la arquitectura del procesador. En cambio el sistema operativo 
lo comunica de ima forma imificada por medio de distintos mecanismos, 
por ejemplo mensajes o senales o deteniendo el proceso que espera la ac- 
cion relacionada con una interrupcion y continuando su ejecucion cuan- 
do esta ocuxre. 

Punto de entrada al sistema operativo Como se vera mas adelante (seccion 
2.7), muchos procesadores y sistemas operatives utilizan las interrupcio- 
nes como medio por el cual un proceso de usuario realiza tma llamada 
al sistema. Por ejemplo, en Linux para arquitecturas x86 el programa de 
usuario genera la interrupcion 0x80 para iniciar una llamada al sistema. 
En arquitecturas mas recientes como x86_64, mips y ARM esto ha sido 
reemplazado por una instruccion especial syscall. 

Atender excepciones y fallas Como se discutio antes, durante la ejecucion de 

un programa pueden ocurrir situaciones anomalas, como por ejemplo, 
una division sobre cero. Desde el pimto de vista del CPU, esto es similar a 
una interrupcion de hardware y debe ser tratada por el sistema operativo. 
Dependiendo de la causa de la excepcion, el sistema operativo tomara 
acdon para resolver en lo posible esta situacion. En muchos casos las 
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excepciones resultan en una senal enviada al proceso, y este ultimo es el 
encargado de tratar la excepcion. En otros casos la falla o excepcion son 
irrecuperables (una instruccion invalida o un error de bus) ante la cual 
el sistema operative terminara el proceso que la genero. En el capitulo 5 
se cubre con mucho mayor detalle un tipo de excepcion muy importante 
que debe tratar el sistema operative: el fallo de paginacion. 

2.3. Las terminales 

Son dispositivos electronicos utilizados para ingresar datos y emitir resul- 
tados dentro de un sistema de computo. Las primeras terminales, tambien 11a- 
madas teletipos, utilizaban tarjetas perforadas e impresiones en papel. Debido 
a su limitada velocidad e imposibilidad de "editar" el papel ya impreso, es- 
tas fueron cediendo terreno ante la entrada, a principios de los setenta, de las 
terminales de texto con pantalla de video y teclado. 

Conceptualmente, una terminal de texto es un dispositive mediante el cual 
la computadora recibe y envia im flujo de caracteres desde y hacia el usuario, 
respectivamente. Las operaciones mas complejas, como edicion, borrado y mo- 
vimiento, en general son tratadas con secuencias de escape, esto es, ima serie de 
caracteres simples que tomados en conjunto representan una accion a realizar 
en la terminal. 

Durante la decada de los setenta tambien se desarrollaron terminales grafi- 
cas, las cuales podian representar imagenes junto con el texto. Con la inclusion 
del raton o mouse estas terminales dieron lugar a lo que hoy se conoce como 
Interfax Grafica de Usuario (Graphical User Interface o GUI y a los sistemas de 
ventana. 

En los sistemas operatives medemes es cemiin referirse al emulador de ter- 
minal, un pregrama especializade, ya sea para tener multiples instancias de 
una terminal, e para ejectuar una terminal de texto dentro de una interfaz gra- 
fica. Estos programas se denominan de esta forma dado que solo replican el 
comportamiento de las terminales (que eran originalmente equipos indepen- 
dientes), siendo linicamente \m programa que recibe la entrada del usuario 
por medio del teclado enviandola al sistema operative come un flujo de da- 
tos, y recibe otro flujo de datos del sistema operative, presentandole de forma 
adecuada al usuario. 

2.4. Dispositivos de almacenamiento 

El almacenamiento en memeria primaria es voldtil, esto es, se pierde al in- 
terrumpirse el suministro electrico. Esto no era muy importante en la epoca 
definitoria de los cenceptes que se presentan en esta seccion, dado que el tiem- 
po total de vida de xa\ conjunto de datos en almacenamiento bajo el control 
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del procesador iba unicamente desde la entrada y hasta el fin de la ejecucion 
del trabajo del usuario. Pero desde la decada de los sesenta se popularize la 
posibilidad de almacenar en la computadora informacion a largo plazo y con 
expectativas razonables de permanencia. 

De las muchas tecnologias de almacenamiento, la que ha dominado fuer- 
temente durante los ultimos 40 anos ha sido la de los discos magneticos.'* El 
acceso a disco (miles de veces mas lento que el acceso a memoria) no es reali- 
zado directamente por el procesador, sino que requiere de la comunicacion con 
controladores externos, con logica propia, que podrlan ser vistos como compu- 
tadoras independientes de proposito limitado. 

El procesador no puede referirse directamente a mas informacion que la 
que forma parte del almacenamiento primario, esto es, de la memoria de ac- 
ceso aleatorio (ram). En las secciones 2.2.2 (Interrupciones y excepciones) y 2.6.2 
{Acceso directo a memoria), se explica como es que se efectuan dichas referencias. 

Los dispositivos de almacenamiento (discos, memorias flash, cintas) pue- 
den ser vistos como una region donde la computadora lee y escribe tma serie 
de bytes que preservaran su valor, incluso luego de apagada la computadora. 

Para el hardware el sistema operative no accede al dispositive de almace- 
namiento byte por byte, sino que estos se agrupan en bloques de tamano fijo. El 
manejo de estos bloques (adminstracion de bloques libres, lectura y escritura) 
es una tarea fundamental del sistema operative, que asimismo se encarga de 
presentar abstracciones come la de archives y directories al usuario. Esto se 
vera en el capltulo 6. 

2.5. Relojes y temporizadores 

Todas las computadoras incluyen uno o mas relojes y temporizadores que 
son utilizados para funciones varias como mantener la hora del sistema actua- 
lizada, implementar alarmas tanto para los programas de usuario como para 
el sistema operative, ejecutar tareas de mantenuniento periodicas, cumplir con 
requisites temporales de aplicaciones de tiempo real, etcetera. 

Mantener el tiempo correctamente dentro del sistema operative es algo cru- 
cial. Permite establecer un orden crenologico entre los eventes que ocurren 
dentro del sistema, por ejemplo, la creacion de uxi archive y de etro o el tiempo 
consumido en la ejecucion de un proceso. 

Por otro lado, si el sistema operative utiliza ima poHtica de planificacion 
de procesos apropiativa (capitulo 4), como la Ronda {Round Robin), este debe 
interrumpir al proceso en ejecucion luego de cierta cantidad de ujnidades de 
tiempo. Esto se implementa haciendo que el temporizador de la computadora 
genere interrupciones periodicamente, lo cual luego invocara al planificador 
de procesos. 

■*Se verin en la seccibn C.1.2 detalles acerca de las tecnologias de almacenamiento en estado 
solido, que pueden poner fin a esta larga dominaci6n. 
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2.6. Canales y puentes 

Los distintos componentes de un sistema de computo se comunican me- 
diante los diferentes canales (generalmente se hace referencia a ellos por su 
nombre en ingles: buses). En el nivel mas basico, los canales son Imeas de comu- 
nicacion entre el procesador y los demas componentes del chipset,^ a los cuales 
a su vez se conectan los diferentes dispositivos del sistema, desde aquellos que 
requieren mayor velocidad, como la misma memoria, hasta los puertos mas 
sencillos. 

Un chipset provee distintos buses, con un agrupamiento logico segiin la ve- 
locidad requerida por sus componentes y otras caracteristicas que determinan 
su topologia. 

Hoy en dia, el acomodo mas frecuente^ de estos buses es por medio de vina 
separacion en dos chips: el puente norte (Northbridge), conectado directamente 
al CPU, encargado de gestionar los buses de mas alta velocidad y que, ademas, 
son ftindamentales para el mas basico inicio de la operacion del sistema: la 
memoria y el reloj. La comunicacion con algunas tarjetas de video se incorpora 
al puente norte a traves del canal dedicado AGP {Advanced Graphics Port, Puerto 
Grafico Avanzado). 

Al puente norte se conecta el puente sur {Southbridge), que controla el res- 
to de los dispositivos del sistema. Normalmente se ven aqui las interfaces de 
almacenamiento (SCSI, SATA, IDE), de expansion interna (PCi, PCie) y de expan- 
sion externa (uSB, Firewire, puertos heredados seriales y paralelos). 

2.6.1. Contencion 

Una de las principales razones de que haya de tantos canales (buses) dis- 
tintos en un mismo sistema se debe a la frecuencia acorde a los dispositivos 
para los cuales esta disenado: la cantidad de datos que tienen que viajar entre 
el procesador y la memoria a lo largo de la operacion del sistema es muy supe- 
rior a la que tienen que transferirse desde los discos, y a su vez, esta es mucho 
mayor que la que se envia a la impresora, o la que se recibe del teclado. Claro 
esta, los demas dispositivos podrian incrementar su frecuencia para participar 
en im canal mas rapido, aunque su costo se incrementaria, dado que harian fal- 
ta componentes capaces de sostener vn reloj varios ordenes de magnitud mas 
rapido. 

Pero incluso obviando la diferencia economica: cuando el sistema requiere 
transferir datos de o hacia varios dispositivos de la misma categoria, es fre- 

^Los chips que forman parte de im equipo, casi siempre provistos por el mismo fabricante que 
el procesador mismo. 

^La separacion aqui descrita ha sido caracteristica de las computadoras x86 de los tiltimos 20 
alios, aimque la tendencia apunta a que se abandone paulatinamente para dar paso a procesadores 
que integren en un s61o paquete todos estos componentes. Sin embargo, el acomodo funcional 
electr6nico, al menos hasta el momento, sigue basado en estos pimtos. 
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Figura 2.3: Diagrama de la comimicacion entre componentes de un sistema de 
computo basado en puente norte y puente sur (imagen de la Wikipedia: Puente Nor- 
te). 



cuente que ocurra contencion: puede saturarse el ancho de banda maximo que 
alcanza uno de los canales y, aun si los dispositivos tienen informacion lista, 
tendran que esperar a que los demas dispositivos desocupen el canal. 

En la figura 2.4 se puede ver el diseno general del chipset Intel 875, introdu- 
cido en el 2003, incluyendo el ancho de banda de cada uno de los canales del 
sistema. Hay que recordar que hay canales como el USB que permiten la cone- 
xion de multiples dispositivos, los cuales deberan compartir el ancho de banda 
total permitido por el canal: en la figura se presentan dos discos duros sobre el 
canal SATA y dos unidades opticas en el ATA paralelo; el canal USB permite el 
uso de un maximo de 127 unidades por canal, por lo cual la contencion puede 
ser muy alta. 
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Dispositivos 
USB 



Figura 2.4: Esquema simplificado del chipset Intel 875 (para el procesador Pentium 
4) Eustrando la velocidad de cada uno de los canales. 



2.6.2. Acceso directo a memoria (DMA) 

La operacion de dispositivos de entrada/ salida puede ser altamente inefi- 
ciente. Cuando iin proceso esta en una seccion limitada por entrada-salida (esto 
es, donde la actividad principal es la transferencia de informacion entre la me- 
moria principal y cualquier otra area del sistema), si el procesador tiene que 
encargarse de la transferencia de toda la informacion'', se crearia un cuello de 
botella por la cantidad y frecuencia de interrupciones. Hoy en dia, para evitar 
que el sistema se demore cada vez que hay una transferencia grande de datos, 
todas las computadoras implementan controladores de acceso directo a memoria 
(DMA, por sus siglas en ingles) en \mo o mas de sus subsistemas. 

El DMA se emplea principalmente al tratar con dispositivos con un gran 
ancho de banda, como unidades de disco, subsistemas multimedia, tarjetas de 
red, e incluso para transferir informacion entre niveles del cache. 

Las transferencias DMA se hacen en bloques preestableddos; en vez de que 
el procesador reciba una interrupcion cada vez que hay ima palabra lista para 
ser almacenada en la memoria, el procesador indica al controlador DMA la di- 
reccion fisica base de memoria en la cual operara, la cantidad de datos a trans- 
ferir, el sentido en que se efectuara la operacion (del dispositivo a memoria o de 
memoria al dispositivo), y el puerto del dispositivo en cuestion; el controlador 
DMA efectuara la transferencia solicitada, y solo vna vez terminada esta (o en 
caso de encontrar algiin error en el proceso) lanzara una interrupcion al siste- 
ma; el procesador queda libre para realizar otras tareas, sin mas limitante que 
la posible contencion que tendra que enfrentar en el bus de acceso a la memoria. 



''Este modo de operaci6n es tambi^n conocido como entrada/salida programada. 
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Coherencia de cache 

Cuando se realiza una transferencia DMA de un dispositive a la memoria, 
puede haber pdginas de la memoria en cuestion que esten en algimo de los nive- 
les de la memoria cache; dado que el cache esta urio o mas niveles por encima 
de la memoria principal, es posible que la informacion haya ya cambiado pero 
el cache retenga la informacion anterior. 

Los sistemas de cache coherente unplementan mecanismos en hardware que 
notifican a los controladores de cache que las paginas que alojan estan sucias y 
deben ser vueltas a cargar para ser empleadas, los sistemas no coherentes requie- 
ren que el subsistema de memoria del sistema operative haga esta operacion. 

Los procesadores actuales implementan normalmente varios niveles de ca- 
che, estando algunos dentro del mismo CPU, por lo que tipicamente se encuen- 
tran sistemas hfbridos, en los que los caches de nivel superiores son coherentes, 
pero los de nivel 1 no, y las inconsistencias que este podria producir deben ser 
esperadas y resueltas por el software.^ 

2.7. Interfaz del sistema operativo: llamadas al sis- 
tema 

De forma analoga a las interrupciones, se puede hablar de las llamadas al 
sistema. El sistema operativo protege a im proceso de otro, y previene que un 
proceso ejecutandose en espacio no privilegiado tenga acceso directo a los dis- 
positivos. Cuando un proceso requiere de alguna accion privilegiada, accede 
a ellas realizando una llamada al sistema. Estas pueden agruparse, a grandes 
rasgos, en: 

Control de procesos Crear o finalizar vm. proceso, obtener atributos del proce- 
so, esperar la finalizacion de un proceso o cierto tiempo, asignar o liberar 
memoria, etcetera. 

Manipulacion de archivos Crear, borrar o renombrar un archivo; abrir o ce- 
rrar \m archivo existente; modificar sus metadatos; leer o escribir de un 
descriptor de archivo abierto, etcetera. 

Manipulacion de dispositivos Solicitar o liberar un dispositive; leer, escribir 

o reposicionarlo, y otras varias. Muchas de estas llamadas son analogas a 
las de manipulacion de archivos, y varios sistemas operatives las efrecen 
come una sola. 

Mantenimiento de la informacion Obtener o modificar la hora del sistema; 
pedir detalles acerca de procesos o archivos, etcetera. 

^El cach6 de nivel 1 puede estar dentro de cada uno de los nticleos, el de nivel 2 se comparten 
entre los nticleos de ttn mismo chip, y el de nivel 3 es extemo y estd en el bus de acceso a memoria. 
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Comunicaciones Establecer una comunicacion con determinado proceso (lo- 
cal o remoto), aceptar una solicitud de comunicacion de otro proceso, 
intercambiar uiformacion sobre un canal establecido. 

Proteccion Consultar o modificar la informacion relativa al acceso de objetos 
en el disco, otros procesos, o la misma sesion de usuario. 

Cada sistema operativo expone una serie de Uamadas al sistema. Estas son, 
a su vez, expuestas al programador mediante de las interfaces de aplicacion al 
programador (API), que se allnean de forma cercana (pero no exacta). Del mismo 
modo que cada sistema operativo ofrece un conjunto de llamadas al sistema 
distinto, cada implementacion de un lenguaje de programacion puede ofrecer 
un API ligeramente distinto de otros. 



Ejecucion 




Llamada 


del proceso... 




al sistema 



Espacio de usuario 



Entrega ejecucion 
al nucleo. Entra en 
^odo protegido. ^^^^^.^ „ ,^|^^ 

Ejecucion de 
la llamada 
al sistema 



Vuelve al 
flujo normal. 
Sale de 
modo protegido J 



Regresa de 
la llamada 
al sistema 



Continua la 
ejecucion... 



Figura 2.5: Transicion del flujo entre espacio usuario y espacio nucleo en una lla- 
mada al sistema. 



2.7.1. Llamadas al sistema, arquitecturas y API 

Cada familia de sistemas operativos provee distintas llamadas al sistema, 
y sus lenguajes/bibliotecas implementan distintos API. Esto es el que distin- 
gue principalmente a uno de otro. Por ejemplo, los sistemas Windows 95 en 
adelante implementan Win32, Winl6 (compatibilidad con Windows previos) y 
MS-DOS; MacOS implementa Cocoa (aplicaciones MacOS x) y Carbon (compa- 
tibilidad con aplicaciones de MacMACOS previos), y Linux, los BSDS, Y VARIOS 
OTROS SISTEMAS, *POSlx (el estandar que define a Unix). El caso de MacOS X es 
interesante, porque tambien implementa POSIX ofreciendo la semdntica de dos 
sistemas muy distintos entre si. 

Los lenguajes basados en mdquinas virtuales abstractas, como Java o la fami- 
lia .NET (vease la seccion B.2.1), exponen un API con mucha mayor distancia 
respecto al sistema operativo; la maqurna virtual se presenta como un pseudo- 
sistema operativo uitermedio que se ejecuta dentro del real, y esta distincion 
se hace especialmente notoria cuando se busca conocer los detalles del sistema 
operativo. 
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Depuracion por trazas (trace) 

La mayor parte de los sistemas operatives ofrecen programas que, para fi- 
nes de depuracion, envuelven al API del sistema y permiten ver la traza de las 
llamadas al sistema que va realizando un proceso. Algunos ejemplos de estas 
herramientas son strace en Linux, truss en la mayor parte de los Unixes 
historicos o ktrace y kdump en los *BSD. A partir de Solaris 10 (2005), Sun 
incluye una herramienta mucho mas profunda y programable para esta tarea 
llamada dtrace, que al paso del tiempo ha sido portada^ a otros Unixes (*BSD, 
MacOS). 

La salida de una traza brinda amplio detalle acerca de la actividad realizada 
por un proceso, y permite comprender a grandes rasgos su interaccion con el 
sistema. El nivel de informacion que da es, sin embargo, a veces demasiado; 
eso se puede ver si se considera la siguiente traza, ante uno de los comandos 
mas sencillos: pwd (obtener el directorio actual) 



1 $ strace pwd 

2 exeove("/bin/pwd", ["pwd"], [/* 43 vars */]) =0 

3 brk(O) = 0x8414000 

4 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such 

file or directory) 

5 inmap2 (NULL, 8192, PROT_READ | PROT_WRITE, 

MAP_PRIVATE I MAP_ANONYMOUS , -1, 0) = 0xb773d000 

6 access ("/etc/Id. so. preload", R_OK) = -1 ENOENT (No such 

file or directory) 

7 open ("/etc/Id. so. cache", 0_RDONLY) = 3 

8 fstat64(3, {st_mode=S_IFREG| 0644, st_size=78233 , ...}) =0 

9 iranap2 (NULL, 78233, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7729000 

10 close(3) = 0 

11 access ("/etc/Id. so. nohwcap" , F_OK) = -1 ENOENT (No such 

file or directory) 

12 open("/lib/i386-linux-gnu/libc.so.6", 0_RDONLY) = 3 

13 read(3, "\177ELF\l\l\l\0\0\0\0\0\0\0\0\0\3\0\3\0\l\0\0\0p" . . . , 

512) = 512 

14 fstat64(3, {st_mode=S_IFREG| 0755, st_size=1351816, ...}) =0 

15 nimap2(NULL, 1366328, PROT_READ | PROT_EXEC , 

MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb75db000 

16 mprotect (Oxb7722000, 4096, PROT_NONE) = 0 

17 mmap2 (0xb7723000, 12288, PROT_READ | PROT_WRITE, 

MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x147) = 0xb7723000 

18 Iimiap2 (0xb7726000, 10552, PROT_READ | PROT_WRITE, 

MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7726000 

19 close (3) = 0 

20 imnap2(NULL, 4096, PROT_READ | PROT_WRITE, 

MAP_PRIVATE I MAP_ANONYMOUS , -1, 0) = 0xb75da000 



'Se denomina portar el hacer las adecuaciones necesarias para que una herramienta disenada 
para determinado entorno pueda emplearse en otros distintos. 
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21 set_thread_area ( {entry_nuinber : -1 -> 6, base_addr : OxbVSdaSdO, 
limit : 1048575, seg_32bit:l, contents :0, read_exec_only : 0 , 
limit_in_pages : 1 , seg_not_present : 0 , useable : 1 } ) = 0 



22 mprotect (Oxb7723000, 8192, PROT_READ) = 0 

23 mprotect (0xb775c000, 4096, PROT_READ) = 0 

24 munmap (0xb7729000, 78233) = 0 

25 brk(O) = 0x8414000 

26 brk (0x8435000) = 0x8435000 



27 open("/usr/lib/locale/locale-archive", 0_RDONLY | 0_IiARGEFILE) = 

3 

28 fstat64(3, {st_mode=S_IFREG| 0644, st_size=1534672 , ...}) =0 

29 mmap2(NULL, 1534672, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7463000 

30 close (3) = 0 

31 getcwd("/home/gwolf/vcs/sistemas_operativos", 4096) = 36 

32 fstat64(l, {st_mode=S_IFCHR| 0620, st_rdev=makedev(136, 1), 

-..}) = 0 

33 mmap2(NULL, 4096, PROT_READ |PROT_WRITE, 

MAP_PRIVATE I MAP_ANONYMOUS , -1, 0) = 0xb773c000 

34 write(l, " /home/gwolf /vcs/sistemas_operati" . . . , 

36/home/gwolf /vcs/sistemas_operativos 

35 ) = 36 

36 close (1) = 0 

37 munmap (0xb773c000, 4096) = 0 

38 close (2) = 0 

39 exit_group ( 0 ) = ? 



2.8. Ref erencia a los componentes 

Si bien el sistema operative tiene por mision abstraer y ocultar los detalles 
de los dispositivos, tambien debe exponer una interfaz para poder emplearlos 
y administrarlos. 

Unix introdujo el concepto de que todo es un archivo: en el sistema Unix ori- 
ginal, todos los dispositivos podlan ser controlados por medio de un archivo 
especial que, en vez de almacenar informacion, apunta a estructuras en el siste- 
ma que controlan a cada dispositivo. Este concepto sobrevive en los sistemas 
derivados de Unix al dla de hoy, aunque varias clases de dispositivo rompen 
esta logica. El sistema operative Plan9 de Bell Labs mantiene y amplla este con- 
cepto e introduce los espacios de nombres mutables, que presenta con interfaz de 
archivo practicamente cualquier objeto empleado por el sistema. 

Las principales estructuras relacionadas de este tipo^*^ que hay en un siste- 
ma tipo Unix son: 



^"Hay varios otros tipos de archivo definidos en su semantica, como las tuberias nombradas, los 
sockets, e incluso los mismos directorios. Estos seran cubiertos en la seccion 6.2.6. 
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Dispositivos de caracteres Son aquellos en los cuales la informacion es leida o 
escrita de a un caracter a la vez y se presentan como streams (flujos) de in- 
formacion, ya sea entrantes, salientes os mixto. Algunos pueden pennitir 
operaciones adicionales (por ejemplo, rebobinado), pero la manipulacion 
de la informacion se efectiia de forma secuencial. Algimos ejemplos de 
estos dispositivos serian la impresora, la imidad de cinta, o el modem. 

Dispositivos de bloques Presentan una interfaz de acceso aleatorio y entregan 
o reciben la informacion en hloques de tamafio predeterminado. El ejem- 
plo mas claro de este tipo de dispositivos es ima imidad de disco o ima 
de sus particiones. 

Por convendon, ambos tipos de archivos de dispositivo estan en el direc- 
torio /dev en los sistemas Unix y siguen ima nomenclatura estandar, aimque 
pueden crearse en cualquier otro lugar 

Ademas de esto, en los sistemas Unix hay sistemas de archivos virtuales con 
informacion de sistema, que se abordan en la seccion 7.1.6. Estos son directo- 
rios cuyos contenidos, si bien se presentan al usuario cual si fueran archivos 
comunes, son mas bien un mecanismo para consultar o manipular las estruc- 
turas internas del micleo. 

En la familia de sistemas operativos derivados de CP/M (el mas popular de 
los cuales hoy en dia es Windows), el mecanismo es muy distinto. Los disposi- 
tivos de aLmacenamiento secundario (discos duros, discos compactos, memo- 
rias flash, etc.) son relacionados con una letra cada vino, asi (en general) C : es 
el volumen o particion del disco principal, A : y B : se utilizan para discos ex- 
trafbles. A los puertos de entrada/salida mas utilizados tambien se les asignan 
nombres alfanumericos, por ejemplo, el primer puerto paralelo se denomina 
LPTl y el segundo puerto serie COM2. La seccion 6.3.3 detalla acerca de la vista 
logica que se presenta en dicho sistema. 

Sin embargo, la mayor parte de los dispositivos e interfaces internas son al- 
canzables linicamente mediante llamadas a sistema, haciendo explicito al desa- 
rrollador (e inalcanzable para el usuario de a pie) que se esta solicitando un 
servicio al sistema opeativo. 

2.9. Cuando dos cabezas piensan mejor que una 

2.9.1. Multiprocesamiento 

El multiprocesamiento es todo entomo donde hay mas de un procesador 
(CPU). En un entorno multiprocesado, el conjunto de procesadores se vuelve 
vin recurso mas a gestionar por el sistema operativo — y el que haya concu- 
rrencia real tiene un fuerte impacto en su diseno. 
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Si bien en el dia a dia se usan de forma intercambiable, es importante 
enfatizar en la diferencia fundamental entre el muUiprocesamiento, que se abor- 
dara en esta seccion, y la multiprogramacidn, de la cual se habla en la seccion 
1.3.3 {Sistemas multiprogramados). Un sistema multiprogramado da la ilusion de 
que esta ejecutando varies procesos al mismo tiempo, pero en realidad esta 
altemando entre los diversos procesos que compiten por su atencion. Un siste- 
ma multiprocesador tiene la capacidad de estar atendiendo simultdneamente a 
diversos procesos. 



A B C A BCABA 
► ►►► ► ►► ► ► 



A I T— >• 

B ► 

C I ► 



B/C I ► ► 

B C B CB 



Figura 2.6: Esquema de la ejecuci6n de tres procesos en un sistema secuencial, mul- 
tiprogramado, multiprocesado, e hibrido. 

En la figura 2.6, el primer diagrama ilustra una ejecucion estrictamente se- 
cuencial: cada vno de los procesos que demandan atencion del sistema es eje- 
cutado hasta que termina; el segundo muestra come se comportaria un sistema 
multiprogramado, altemando entre los tres procesos, de modo que el usuario 
vea que los tres avanzan de forma simultanea; el tercero corresponde a un sis- 
tema de multitarea pura: cada proceso es ejecutado por un procesador distinto, 
y avanzan en su ejecucion de forma simultanea. El cuarto caso, un esquema hi- 
brido, presenta como reaccionaria un equipo con capacidad de atender a dos 
procesos al mismo tiempo, pero con tres procesos solicitando ser atendidos. 
Este ultimo esquema es el que mas comujnmente se encuentra en equipos de 
uso general hoy en dia. 

Probablemente el tema que se aborda mas recurrentemente a lo largo de 
este texto sera precisamente la complejidad que proviene de la multiprogra- 
macidn; se la desarroUara particularmente en los capitulos 3 y 4. Valga la nota 
en este momento linicamente para aclarar la diferencia entre los dos conceptos. 

El multiprocesamiento se emplea ampliamente desde los sesenta en los en- 



^^O poco m^s que eso, al grado de que rara vez se emplea el t^rmino multiprogratnacion, mucho 
mds acorde con los equipos que se emplean dia a dta. 
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tornos de computo de alto rendimiento, pero por muchos anos se vio como 
el area de especializacion de muy pocos; las computadoras con mas de un 
procesador eran prohibitivamente caras, y para muchos sistemas, ignorar el 
problema resultaba una opcion valida. Muchos sistemas operativos ni siquiera 
detectaban la presencia de procesadores adicionales, y en presencia de estos, 
ejecutaban en ujno solo. 




(no — cyiOTinujNoooio — cvJiOTio 
o><i>oioioiaio>oi<n(7>oio>0>(n(it(noi 

YEAR 



Figura 2.7: La Ley de Moore, en su articulo publicado en 1965, prediciendo la minia- 
turizacion por 10 anos. 



Esto cambio hacia el 2005. Tras mas de 40 anos de cumplirse, el modelo co- 
nocido como la Ley de Moore, enunciando que cada dos anos la densidad de 
transistores por circuito integrado se duplicarla, llevaba a velocidades de CPU 
que, en el ambito comercial, excedian los 3 GHz, lo cual presentaba ya proble- 
mas serios de calentamiento. Ademas, el diferencial de velocidad con el acceso 
a memoria era cada vez mas alto. Esto motivo a que las principales compahlas 
productoras de los CPU cambiaran de estrategia, introduciendo chips que son, 
para propositos practicos, paquetes con dos o mas procesadores dentro. 

Con este cambio, el reloj de los procesadores se ha mantenido casi sin cam- 
bios, cerca de 1 GHz, pero el rendimiento de los equipos sigue aumentando. Sin 
embargo, los programadores de sistemas operativos y programas de aplicacion 
ya no pueden ignorar esta complejidad adicional. 

Se denomina multiprocesamiento simetrico (tlpicamente abreviado SMP) a la 
situacion en la que todos los procesadores del sistema son iguales y pueden 
realizar en el mismo tiempo las mismas operaciones. Todos los procesadores 
del sistema tienen acceso a la misma memoria (aunque cada uno puede tener 
su propio cache, lo cual obliga a mantener en mente los puntos relacionados 
con la coherencia de cache abordados en la seccion anterior). 

En contraposicion, puede hablarse tambien del multiprocesamiento asimetri- 
co; dependiendo de la implementacion, la asimetria puede residir en diferentes 
puntos. Puede ir desde que los procesadores tengan ima arquitectura distinta 
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Figura 2.8: La Ley de Moore se sostiene al dia de hoy: conteo de transistores por 
procesador de 1971 al 2012. 



(tipicamente dedicada a una tarea especifica), en cuyo caso pueden verse co- 
mo coprocesadores o procesadores coadyuvantes, casi computadoras independien- 
tes contribuyendo sus resultados a un mismo computo. Hoy en dia, este seria el 
caso de las tarjetas graficas 3D, que son computadoras completas con su propia 
memoria y responsabilidades muy distintas del sistema central. 

Es posible tener diferentes procesadores con la misma arquitectura pero 
funcionando a diferente frecuencia. Esto conlleva una fuerte complejidad adi- 
cional, y no se utiliza hoy en dia. 

Por ultimo, se tienen los disenos de Acceso No-Uniforme a Memoria {Non- 
Uniform Memory Access, NUMA). En este esquema, cada procesador tiene afi- 
nidad con bancos especificos de memoria: para evitar que los diferentes pro- 
cesadores esten esperando al mismo tiempo al bus compartido de memoria, 
cada uno tiene acceso exclusivo a su area. Los sistemas NUMA pueden ubicarse 
como en un punto intermedio entre el procesamiento simetrico y el computo 
distribuido, y puede ser visto como un computo distribuidofuertemente acoplado. 

2.9.2. Computo distribuido 

Se denomina computo distribuido a un proceso de computo realizado entre 
computadoras independientes, o, mas formalmente, entre procesadores que no 
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comparten memoria (almacenamiento primario). Puede verse que un equipo de 
diseno NUMA esta a medio cainino entre una computadora multiprocesada y 
el computo distribuido. 

Hay diferentes modelos para implementar el computo distribuido, siempre 
basados en la transmision de datos sobre una red. Estos son principalmente: 

Cumulos (clusters) Computadoras conectadas por una red local (de alta ve- 
locidad), ejecutando cada una su propia instancia de sistema operativo. 
Pueden estar orientadas al alto rendimiento, alta disponibilidad o al balanceo 
de cargas (o a una combinacion de estas). Tlpicamente son eqmpos homo- 
geneos, y dedicados a la tarea en cuestion. 

Mallas (Grids) Computadoras distribuidas geograficamente y conectadas me- 
diante una red de comunicaciones. Las computadoras participantes pue- 
den ser heterogeneas (en capacidades y hasta en arquitectura); la comu- 
nicacion tiene que adecuarse a enlaces de mucha menor velocidad que en 
el caso de im cluster, e incluso presentar la elasticidad para permitir las 
conexiones y desconexiones de nodos en el transcurso del computo. 

Computo en la nube Un caso especifico de computo distribuido con particion 
de recursos (al estilo del modelo cliente-servidor); este modelo de servi- 
cio esta fuertemente orientado a la tercerizacion de servicios especfficos. 
A diferencia del modelo cliente-servidor tradicional, en un entorno de 
computo en la nube lo mas comiin es que tanto el cliente como el servi- 
dor sean procesos que van integrando la informacion, posiblemente por 
muchos pasos, y que solo eventuabnente Uegaran a un usuario final. La 
implementacion de cada uno de los servicios empleados deja de ser re- 
levante, para volverse un servicio opaco. Algunos conceptos relacionados 
son: 

Servicios Web Mecanismo de descripcion de funcionalidad, asf como de 
solicitud y recepcion de resultados, basado en el estandar http y 
contenido XML. 

Software como servicio El proveedor ofrece una aplicacion completa y ce- 
rrada sobre la red, exponiendo linicamente su interfaz (API) de con- 
sultas. 

Plataforma como servicio El proveedor ofrece la abstraccion de un en- 
torno especifico de desarrollo de modo que un equipo de programa- 
dores pueda desplegar una aplicacion desarroUada sobre dicha pla- 
taforma tecnologica. Puede ser visto como un conjunto de piezas de 
infraestructura sobre tm servidor administrado centralmente. 

Infraestructura como servicio El proveedor ofrece computadoras com- 
pletas (en hardware real o maquinas virtuales); la principal ventaja 
de esta modalidad es que los usuarios, si bien retienen la capacidad 
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plena de administracion sobre sus granjas, tienen mucho mayor fle- 
xibilidad para aumentar o reducir el consumo de recursos (y, por 
tanto, el pago) segun la demanda que alcancen. 

El tema del computo en la nube va muy de la mano de la virtualizacion, 
que se abordara en el apendice B. 

2.9.3. Amdahl y Gustaf son: ique esperar del paralelismo? 

Al programar una aplicacion de forma que aproveche al paralelismo (esto 
es, disenarla para que realice en distintos procesadores o nodos sus porciones 
paralelizables) ^cual es el incremento al rendimiento que se puede esperar? 

En 1967, Gene Amdahl presento un artfculo^'^ en el que indica los limites 
maximos en que resultara la programacion multiprocesada ante un determina- 
do programa: parte de la observacion de que aproximadamente 40% del tiempo 
de ejecucion de un programa se dedicaba a la administracion y el mantenimien- 
to de los datos, esto es, a tareas secuenciales. 

Si unicamente el 60% del tiempo de procesamiento es susceptible, pues, de 
ser paralelizado, el rendimiento general del sistema no se incrementara en una 
proporcion directa con el mimero de procesadores, sino que debe sumarsele la 
porcion estrictamente secuencial. Puesto en terminos mas formales: la ganan- 
cia en la velocidad de ejecucion de un programa al ejecutarse en un entomo 
paralelo estara limitado por el tiempo requerido por su fraccion secuencial. Es- 
to significa que, si T(l) representa al tiempo de ejecucion del programa con un 
solo procesador, T(P) al tiempo de ejecucion con P procesadores, tg al tiempo 
requerido para ejecutar la porcion secuencial del programa, y tp{P) el tiempo 
que necesita la ejecucion de la porcion paralelizable, repartida entre P procesa- 
dores, se puede hablar de una ganancia g en terminos de: 

Esta observacion, conocida como la Ley de Amdahl, Uevo a que por varias 
decadas el computo paralelo fuera relegado al computo de proposito espedfi- 
co, para necesidades muy focalizadas en soluciones altamente paralelizables, 
como el computo cientffico. 

En terminos del ejemplo presentado en la figura 2.9, se ve un programa que, 
ejecutado secuencialmente, resulta en T = 500. Este programa esta dividido en 
tres secciones secuenciales, det — 100 cada una, y dos secciones paralelizables, 
totalizando t — 100 cada ima, como se puede ver al representar una ejecucion 
estrictamente secuencial (2.9(a)). 



^^"Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities", 
Amdahl, 1967 
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f = 500 400, ganancia: 1.25x 



Figura 2.9: Ley de Amdahl: ejecuci6n de un programa con 500 unidades de tiempo 
total de trabajo con uno, dos y cuatro procesadores. 



Al agregar un procesador adicional (2.9(b)), se obtiene una ganancia de 
1.25x — la ejecucion se completa en T = 400 (con g = 1,25). Las secciones 
paralelizables solo toman un tiempo externa de 50 cada tina, dado que la carga 
fue repartida entre dos unidades de ejecucion. Al ejecutar con cuatro procesa- 
dores (2.9(c)), si bien se sigue notando mejoria, esta apenas Ueva a T = 350, con 

Si el codigo fuera infinitamente paralelizable, y se ejecutase este programa 
en una computadora con un ntimero infinito de procesadores, este programa 
no podria ejecutarse en menos de T = 300, lo cual presentaria una ganancia de 
apenas g — 1,66. Esto es, al agregar procesadores adicionales, rapidamente se 
llegaria a un crecimiento asintotico — el comportamiento descrito por la Ley de 
Amdahl es frecuentemente visto como una demostracion de que el desarrollo 
de sistemas masivamente paralelos presenta rendimientos decrecientes. 

Si bien el ejemplo que se acaba de presentar resulta poco optimizado, con 
solo un 40% de codigo paralelizable, se puede ver en la grafica 2.10 que el pa- 
norama no cambia tan fuertemente con cargas tlpicas. Un programa relativa- 
mente bien optimizado, con 80% de ejecucion paralela, presenta un crecimiento 
atractivo en la region de hasta 20 procesadores, y se estaciona apenas arriba de 
una ganancia de 4.5 a partir de los 40.^^ Incluso el hipotetico 95% Uega a ujn. 
tope en su crecimiento, imposibilitado de alcanzar ujna ganancia superior a 20. 

Dado que el factor economico resulta muy importante para construir 



'De un m^ximo de cinco al que puede alcanzar con un ntimero infinito de procesadores. 
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Figura 2.10: Ganancia maxima al paralelizar un programa, segun la Ley de Am- 
dahl. 



computadoras masivamente paralelas, y que se ve claramente que el poder 
adicional que da cada procesador es cada vez menor, la Ley de Amdahl re- 
sulto (como ya se menciono) en varias decadas de mucho mayor atencion a la 
miniaturizacion y aumento de reloj, y no al multiprocesamiento. 

Fue hasta 1988 que John Gustafson publico una observacion a esta ley^^ 
que, si bien no la invalida, permite verla bajo una luz completamente diferente 
y mucho mas optimista. Gustafson publico este articulo corto tras haber obte- 
nido ganancias superiores a 1 020 en una supercomputadora con 1 024 procesa- 
dores: un incremento casi perfectamente lineal al numero de procesadores. Si, 
respondiendo a una carga altamente optimizada, pero no por eso menos digna 
de analisis. 

El argumento de Gustafson es que al aumentar el numero de procesadores, 
tipicamente se vera una modificacion al problema mismo. Citando de su articulo 
(traduccion propia), 

(. . . )Asumen implfcitamente que el tiempo en el que se ejecuta en 
paralelo es independiente del niimero de procesadores, lo que vir- 
tualmente nunca ocurre de este modo. Uno no toma un problema de 
tamano fijo para ejecutarlo en varios procesadores como no sea pa- 
ra hacer un ejercicio academico; en la practica, el tamano del problema 
crece con el numero de procesadores. Al obtener procesadores mas po- 
derosos, el problema generalmente se expande para aprovechar las 
facilidades disponibles. Los usuarios tienen control sobre cosas co- 
mo la resolucion de la malla, el niimero de pasos, la complejidad de 

^^Dado que los componentes mas caros son necesariamente los procesadores. 
^^"Reevaluating Amdahl's Law", John L. Gustafson, "Communications of the ACM", vol. 31, 
mayo de 1988 
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los operadores y otros parametros que usualmente se ajustan para 
permitir que el programa se ejecute en el tiempo deseado. For tan- 
to, podria ser mas realista que el tiempo de ejecucion, no el tamano del 
problema, es constante. 

Lo que escribe Gustafson se traduce a que es posible obtener la eficiencia 
deseada de cualquier cantidad de procesadores aumentando suficientemente el 
tamano del problema. Al enfrentarse expHcitamente con el bloqueo mental contra 
el paralelismo masivo que naci6 de esta lectura erronea de lo comentado por 
Amdahl, su articulo sencillo y de apenas mas de una cuartilla de extension 
cambio la percepcion acerca de la utilidad misma del paralelismo masivo. 

2.10. Ejercicios 

2.10.1. Preguntas de autoevaluacion 

1. De las siguientes opciones, ^cual responde a la definicion de almacena- 
miento primario? 

a) Las unidades de aknacenamiento no volatil de largo plazo (discos, 
memoria Flash, USB, etcetera) 

b) La memoria RAM del sistema. 

c) La capa de memoria que corre a mayor velocidad y esta mas cerca 
del procesador. 

d) Los registros, espacio de memoria de extremadamente alta veloci- 
dad ubicados dentro del mismo procesador. 

2. Los primeros procesadores teman un linico registro de proposito general, 
llamado tambien acumulador. Los procesadores actuales tienen 32 o hasta 
64. ^Cuales son las principales ventajas y desventajas de esta tendencia? 

3. ^Cual es el maximo de informacion (en bytes) que puede transferir a me- 
moria en un segundo un disco con un tiempo de acceso de 15 ms y una 
tasa de transferencia de 80 MB por segundo? 

4. De la siguiente lista de eventos, indique cuales que corresponden a inte- 
rrupciones y cuales a excepciones 

a) El usuario acciono algima tecla. 

b) Se produjo un acceso ilegal a memoria fuera del segmento {segmen- 
tation fault). 

c) El proceso en ejecucion lanzo una llamada al sistema. 

d) Llego un paquete a la interfaz de red. 
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e) Se produjo una division sobre cero. 

/) El proceso en ejecucion estuvo activo ya demasiado tiempo, es hora 
de un cambio de contexto. 

g) Los datos solicitados al controlador de disco duro ya estan disponi- 
bles. 

5. Si el procesador de un sistema corre a 1 GHz, la latencia de la memoria 
es de 130ns, y el bus de memoria puede sostener un ancho de banda de 
3 000 MB por segundos, asumiendo que no hay ningun otro proceso en 
ejecucion que entorpezca el proceso, ^cuantos ciclos de reloj tiene que 
esperar el procesador al solicitar una palabra (64 bits)? 

2,10.2, Temas de investigacion sugeridos 

Rootkits: Escondiendose del administrador Complementando a la division 
de espacio usuario y espacio kernel, cabe pregimtarse acerca de como 
se pueden hurlar los mecanismos de segiiridad. 

Si bien a estas alturas del texto aun no se ha profundizado en muchos de 
estos temas, un enfoque podria comenzazr con enumerar las amenazas: 
Una vez que un atacante logro romper un programa al que tenia acceso, 
enganando al sistema operativo para que le de acceso privilegiado, bus- 
cara para esconder sus rastros del administrador y, ademas, asegurarse 
de tener un mecanismo facil para entrar posteriormente. ^Como lo hace, 
como se puede detectar? 

Sistemas basados en tnalla o grid El modelo de computo distribuido basado 
en una malla o grid es muy flexible, y lo han adoptado proyectos de todo 
tipo. ^Que es lo que se distribuye, como se paquetiza la informacion, como 
se re-agrega, que tanto costo computacional adicional significa el separar 
en estos paquetes a la informacion? 

Se puede emplear un modelo grid con participantes conocidos, con una 

membresia predeterminada, pero muchos proyectos lo abren a participa- 
cion piiblica. ^Hay consideraciones de seguridad a tomar en cuenta? 

El Modulo de Plataforma Confiable (tpm o SecureBoot) Tras largos anos de 
encontrar gran resistencia por parte de la industria, al dia de hoy bue- 
na parte de las computadoras nuevas vienen con un modulo de plataforma 
confiable {Trusted Platform Module) activo. Este polemico modulo imple- 
menta verificacion de la integridad del sistema operativo, evitando que 
un ataque (sea un virus o \m agente hostil) ejecute codigo que altere la ope- 
racion del sistema operativo o incluso ejecute antes de este y lo envuelva 
(por ejemplo, en un esquema de virtualizacion). 



68 



CAPITULOZ. RELACION CON EL HARDWARE 



El esquema TPM, sin embargo, tambien puede evitar que el dueno de una 
computadora la use como el quiera, forzandolo a ejecutar unicamente los 
sistemas operativos aprobados ofirmados por el fabricante. 

Como lectura para este tema resultan referenda obligada los diversos ar- 
ticulos en el blog del desarrollador Matthew Garrett, particularmente en- 
tre septiembre del 2011 y mayo del 2013. Garrett lidereo la altemativa 
que al dia de hoy mas se usa para poder iniciar Linux en \m sistema bajo 
TPM; tiene decenas de artfculos desde muy descriptivos y generales hasta 
tecnicos y especlficos a puntos muy particulares. 

Otro articulo interesante al respecto es el de Jonathan Corbet (septiembre 
2013): BSD-style securelevel comes to Linux — Again. Explica con bas- 
tante detalle como es que se plantea implementar el nivel de proteccion 
que busca ofrecer tpm desde im sistema Linux. 

2.10.3. Lecturas relacionadas 

■ Can programming be liberated from the von Neumann style?: afunctional style 
and its algebra of programs 

https : //dl . acm. org/citation.cfm? do id= 359576. 359579 
John Backus, 1978; Communications of the ACM 

■ Cramming more components onto integrated circuits 

http : //cs .utexas . edu/~fussell/courses/cs352h/papers/moore .pdf 
Gordon E. Moore, 1965; Proceedings of the IEEE 

■ An Introduction to the Intel® QuickPath Interconnect 

http : / /www . Intel . com/content/ www/us/ en/ io/ quickpath-technology/ 
quick-path-interconnect-introduction-paper . html 

Intel, 2009 (Dociunent Number: 320412-OOlUS) 

■ Intel® Desktop Board D875PBZ Technical Product Specification 

http : //downloadmirror . Intel . com/15199/eng/D875PBZ_TechProdSpec . 

pdf 

(Intel, 2003) 
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Administracion de procesos 



3.1. Concepto y estados de un proceso 

En un sistema multiprogramado o de tiempo compartido, un proceso es la 
imagen en memoria de un programa, junto con la informacion relacionada con 
el estado de su ejecucion. 

Un programa es una entidad pasiva, una lista de instrucciones; un proceso 
es una entidad activa, que -empleando al programa- define la actuacion que 
tendra el sistema. 

En contraposicion con proceso, en un sistema por lotes se habla de tareas. 
Una tarea requiere mucha menos estructura, tipicamente basta con guardar 
la informacion relacionada con la contabilidad de los recursos empleados. Una 
tarea no es interrumpida en el transcurso de su ejecucion. Ahora bien, esta dis- 
tincion no es completamente objetiva — y se pueden encontrar muchos textos 
que emplean indistintamente vna u otra nomenclatura. 

Si bien el sistema brinda la ilusion de que muchos procesos se estan ejecu- 
tando al mismo tiempo, la mayor parte de ellos tipicamente esta esperando 
para continuar su ejecucion — en un momento determinado solo puede estar 
ejecutando sus instrucciones im niimero de procesos igual o menor al mimero 
de procesadores que tenga el sistema. 

En este capitulo se desarrollan los conceptos relacionados con procesos, hi- 
los, concurrencia y sincronizacion — las tecnicas y algoritmos que emplea el 
sistema operativo para determinar como y en que orden hacer los cambios de 
proceso que brindan al usuario la ilusion de simultaneidad se abordaran en el 
capitulo 4. 

3.1.1. Estados de un proceso 

Un proceso, a lo largo de su vida, alterna entre diferentes estados de ejecu- 
cion. Estos son: 
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Nuevo Se solicito al sistema operative la creacion de un proceso, y sus recuxsos 
y estructuras estan siendo creadas. 

Listo Esta listo para iniciar o continuar su ejecucion pero el sistema no le ha 
asignado \m procesador. 

En ejecucion El proceso esta siendo ejecutado en este momento. Sus instruc- 
ciones estan siendo procesadas en algiin procesador. 

Bloqueado En espera de algiin evento para poder continuar su ejecucion (aim 
si hubiera un procesador disponible, no podrla avanzar).pcb 

Zombie El proceso ha finalizado su ejecucion, pero el sistema operative debe 
realizar ciertas operaciones de limpieza para poder eliminarlo de la lista.^ 

Terminado El proceso termino de ejecutarse; sus estructuras estan a la espera 
de ser limpiadas por el sistema operative. 



NuGVO 




Figura 3.1: Diagrama de transicion entre los estados de un proceso. 



3.1.2. Infonnacion asociada a un proceso 

La informacion que debe manipular el sistema operative relativa a cada uno 
de los procesos actuales se suele aLmacenar en una estructura llamada bloque de 
control de proceso (PCB - Process Control Block). El PCB incluye campos como: 



^Estas operaciones pueden incluir notificar al proceso padre, cerrar las conexiones de red que 
tenia activas, liberal memoria, etcetera. 
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Estado del proceso El estado actual del proceso. 

Contador de programa Cual es la siguiente instruccion a ser ejecutada por el 
proceso. 

Registros del CPU La informacion espedfica del estado del CPU mientras el 
proceso esta en ejecucion (debe ser respaldada y restaiirada cuando se 
registra un cambio de estado). 

Informacion de planificacion (scheduling) La prioridad del proceso, la cola 
en que esta agendado, y demas informacion que puede ayudar al sis- 
tema operativo a planificar los procesos; se profundizara en este tema en 
el capltulo 4. 

Informacion de administracion de memoria La informacion de mapeo de me- 
moria (paginas o segmentos, dependiendo del sistema operativo), inclu- 
yendo la pila (stack) de llamadas. Se abordara el tema en el capitulo 5. 

Informacion de contabilidad Informacion de la utilizacion de recursos que ha 
tenido este proceso — puede incluir el tiempo total empleado y otros (de 
usuario, cuando el procesador va avanzando sobre las instrucciones del 
programa propiamente, de sistema cuando el sistema operativo esta aten- 
diendo las solicitudes del proceso), uso acumulado de memoria y dispo- 
sitivos, etcetera. 

Estado de E/S Listado de dispositivos y archivos asignados que el proceso tie- 
ne abiertos en un momento dado. 

3.2. Procesos e hilos 

Como se vio, la cantidad de informacion que el sistema operativo debe ma- 
nejar acerca de cada proceso es bastante significativa. Si cada vez que el pla- 
nificador elige que proceso pasar de Listo a En ejecucion debe considerar buena 
parte de dicha informacion, la simple transferencia de todo esto entre la me- 
moria y el procesador podria Uevar a un desperdicio burocrdtico^ de recursos. 
Una respuesta a esta problematica fue la de utilizar los hilos de ejecucion, a veces 
conocidos como procesos ligeros (lwp. Lightweight processes). 

Cuando se consideran procesos basados en un modelo de hilos, se puede 
proyectar en sentido inverso que todo proceso es como im solo hilo de eje- 
cucion. Un sistema operativo que no ofreciera soporte expreso a los hilos los 
planificaria exactamente del mismo modo. 

^Entendiendo burocratico como el tiempo que se pierde en asuntos administrativos. Recordar 
que el tiempo que consume el sistema operativo en administraci6n es tiempo perdido para el uso 
real, productivo del equipo. 
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Pero visto desde la perspectiva del proceso hay una gran diferencia: si bien 
el sistema operative se encarga de que cada proceso tenga una vision de virtual 
exclusividad sobre la computadora, todos los hilos de un proceso comparten 
un solo espacio de direccionamiento en memoria y los archivos y dispositivos 
abiertos. Cada uno de los hilos se ejecuta de forma (aparentemente) secuen- 
cial y maneja su propio contador de programa y pila (y algunas estructuras 
adicionales, aunque mucho mas ligeras que el pcb). 

3.2.1. Los hilos y el sistema operativo 

La programacion basada en hilos puede hacerse completamente y de forma 
transparente en espacio de usuario (sin involucrar al sistema operativo). Estos 
hilos se llaman hilos de usuario (user threads), y muchos lenguajes de programa- 
cion los denominan hilos verdes {green threads). Un caso de uso interesante es en 
los sistemas operatives mrnimos (p. ej. para dispositivos embebidos), capaces 
de ejecutar una maquina virtual (ver seccion B.2.1) de algvino de esos lengua- 
jes: si bien el sistema operativo no maneja multiprocesamiento, mediante los 
hilos de usuario se crean procesos con multitarea interna. 

Los procesos que implementan hilos ganan un poco en el rendimiento gra- 
cias a no tener que reemplazar al PCB activo cuando intercalan la ejecucion 
de sus diferentes hilos; pero ademas de esto, ganan mucho mas por la ventaja 
de compartir espacio de memoria sin tener que establecerlo expllcitamente a 
traves de mecanismos de comunicacion entre procesos (IPC, Inter Process Commu- 
nications). Dependiendo de la plataforma, a veces los hilos de usuario inclusi- 
ve utilizan multitarea cooperativa para pasar el control dentro de un mismo 
proceso. Cualquier Uamada al sistema bloqueante (como obtener datos de un 
archivo para utilizarlos inmediatamente) interrumpira la ejecucion de todos los 
hilos de ese proceso, dado que el control de ejecucion es entregado al sistema 
operativo quien en este caso no conoce nada sobre los hilos. 

Continuando con el desarrollo historico de este mecanismo, el siguiente 
paso fue la creacion de hilos informando al sistema operativo, tipicamente de- 
nominados hilos de kernel {kernel threads). Esto se hace a traves de bibliotecas 
de sistema que los implementan de forma estandar para los diferentes siste- 
mas operatives o arquitecturas (p. ej. pthreads para POSIX o Win32_Thread 
para Windows). Estas bibliotecas aprovechan la comunicacion con el sistema 
operativo tanto para solicitudes de recursos (p. ej. un proceso basado en hi- 
los puede beneficiarse de una ejecucion verdaderamente paralela en sistemas 
multiprocesador) como para una gestion de recursos mas comparable con una 
situacion de multiproceso estandar. 

3.2.2. Patrones de trabajo con hilos 

Hay tres patrones en los que caen generalmente los modelos de hilos; se 
puede emplear mas de vino de estos patrones en diferentes areas de cada apli- 
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cacion, e incluso se pueden anidar (esto es, se podria tener una Unea de ensam- 
blado dentro de la cual uno de los pasos sea un equipo de trabajo): 

Jefe/trabajador Un hilo tiene una tarea distinta de todos los demas: el hilo jefe 
genera o recopila tareas para realizar, las separa y se las entrega a los hilos 
trabajadores. 

Este modelo es el mas comun para procesos que implementan servidores 
(es el modelo clasico del servidor Web Apache) y para aplicaciones grafi- 
cas (GUI), en que hay una porcion del programa (el hilo jefe) esperando a 
que ocurran eventos externos. El jefe realiza poco trabajo, se limita a in- 
vocar a los trabajadores para que hagan el trabajo de verdad; como mucho, 
puede llevar la contabilidad de los trabajos realizados. 

Tipicamente, los hilos trabajadores realizan su operacion, posiblemente 
notifican al jefe de su trabajo, yfinalizan su ejecucion. 



Jefe (espera evento) 




Figura 3.2: Patron de hilos jefe/ trabajador. 

Equipo de trabajo al iniciar la porcion multihilos del proceso, se crean muchos 
hilos identicos, que realizaran las mismas tareas sobre diferentes datos. 
Este modelo es frecuentemente utilizado para calculos matematicos (p. 
ej.: criptografla, render, algebra lineal). Puede combinarse con un estilo 
jefe/trabajador para irle dando al usuario una previsualizacion del resul- 
tado de su calculo, dado que este se ira ensamblando progresivamente, 
pedazo por pedazo. 

Su principal diferencia con el patron jefe/trabajador consiste en que el tra- 
bajo a realizar por cada uno de los hilos se plantea desde principio, esto 
es, el paso de division de trabajo no es un hilo mas, suio que prepara los 
datos para que estos sean lanzados en paralelo. Estos datos no son resul- 
tado de eventos independientes (como en el caso anterior), suio partes de 
un solo calculo. Como consecuencia, resulta natural que en este modelo 



74 



CAPITULO 3. ADMINISTRACION DE PROCESOS 



los resultados generados por los diferentes hilos son agregados o totali- 
zados al terminar su procesamiento. Los hilos no terminan, sino que son 
sincronizados y luego continuan la ejecucion lineal. 



Division de trabajo 



'Datos 1 





a 


Hilo 
1 


b 




c 



Datos 2 \Datos 3 





e 


1 


Hilo 


b 


2 








c 



Resultados 1 





a 


Hilo 
3 


b 




c 



Resultados 2)Resultados 3 



Agregacion de resultados 



Figura 3.3: Patron de hilos Equipo de trabajo. 



Linea de ensamblado si una tarea larga puede dividirse en pasos sobre blo- 
ques de la informacion total a procesar, cada hilo puede enfocarse a hacer 
solo un paso y pasarle los datos a otro hilo conforme vaya terminando. 
Una de las principales ventajas de este modelo es que ayuda a mantener 
rutinas simples de comprender, y permite que el procesamiento de datos 
continue, incluso si parte del programa esta bloqueado esperando E/ S. 



Un punto importante a tener en cuenta en una linea de ensamblado es 
que, si bien los hilos trabajan de forma secuencial, pueden estar ejecutan- 
dose paralelamente sobre bloques consecutivos de informacion, eventos, 
etcetera. 



Este patron es claramente distinto de los dos anteriormente presentados; 
si bien en los anteriores los diferentes hilos (a excepcion del hilo jefe) 
eran casi siempre identicos -aunque operando sobre distrntos conjuntos 
de datos-, en este caso son todos completamente distintos. 
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Hilo 
1 




Hilo 
2 




Hilo 
3 


a 1 b 1 c 


m 1 n 


w 1 X 1 y 1 z 







Figura 3,4: Patron de hilos Lmea de ensamhlado. 



3.3. Concurrencia 

3.3.1. Introduccion 

Desde un punto de vista formal, la concurrencia no se refiere a dos o mas 
eventos que ocurren a la vez sino a dos o mas eventos cuyo orden es no determi- 
nista, esto es, eventos acerca de los cuales no se puede predecir el orden relativo en 
que ocurrirdn. Si bien dos procesos (o tambien dos hilos) completamente inde- 
pendientes entre si ejecutandose simultaneamente son concurrentes, los temas 
que en la presente seccion se expondran se ocupan principalmente de proce- 
sos cuya ejecucion esta vinculada de alguna manera (p. ej.: dos procesos que 
comparten cierta informacion o que dependen uno del otro). 

Aunque una de las tareas principales de los sistemas operativos es dar a 
cada proceso la ilusion de que se esta ejecutando en una computadora dedi- 
cada, de modo que el programador no tenga que pensar en la competencia 
por recursos, a veces un programa requiere interactuar con otros: parte del 
procesamiento puede depender de datos obtenidos en fuentes extemas, y la 
cooperacion con hilos o procesos externos es fundamental. 

Se vera que pueden aparecer muchos problemas cuando se estudia la inter- 
accion entre hilos del mismo proceso, la srncronizacion entre distrntos proce- 
sos, la asignacion de recursos por parte del sistema operativo a procesos simul- 
taneos, o incluso cuando interactuan usuarios de diferentes computadoras de 
una red — se presentaran distrntos conceptos relacionados con la concurrencia 
utilizando uno de esos escenarios, pero muchos de dichos conceptos en reali- 
dad son independientes del escenario: mas bien esta seccion se centra en la 
relacion entre procesos que deben compartir recursos o sincronizar sus tareas. 

Para presentar la problematica y los conceptos relacionados con la concu- 
rrencia suelen utilizarse algunos problemas clasicos, que presentan casos parti- 
culares muy simplificados, y puede encontrarseles relacion con distintas cues- 
tiones que un programador enfrentara en la vida real. Cada ejemplo presenta 
uno o mas conceptos. Se recomienda comprender bien el ejemplo, el problema 
y la solucion y desmenuzar buscando los casos llmite como ejercicio antes de 
pasar al siguiente caso. Tambien podrla ser litil imagrnar en que circunstancia 
un sistema operativo se encontrarla en una situacion similar. 

Para cada problema se mostrara una forma de resolverlo aunque en gene- 
ral hay mas de una solucion valida. Algunos de estos fueron origrnalmente 
planteados como justificacion del desarrollo de las estructuras de control pre- 
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sentadas o de nuevos paradigmas de concurrencia y muchos son aun objeto de 
debate e investigacion. 

Para profundizar mas en este tema, se recomienda el libro The little book 
of semaphores de Allen Downey (2008). En este libro (de libre descarga) se 
encuentran muchos ejemplos que ilustran el uso de semaforos, no solo para 
resolver problemas de sincronizacion, sino como un mecanismo simple de co- 
municacion entre procesos. Tambien se desarrollan distintas soluciones para 
los problemas clasicos (y no tan clasicos). 

3.3.2. Problema: el jardm ornamental 

Descripcion del problema 

Un gran jardln ornamental se abre al publico para que todos puedan apre- 
ciar sus fantasticas rosas, arbustos y plantas acuaticas. Por supuesto, se cobra 
una modica suma de dinero a la entrada para lo cual se colocan dos torni- 
quetes, uno en cada una de sus dos entradas. Se desea conocer cuanta gente 
ha uigresado al jardln asl que se instala una computadora conectada a ambos 
torniquetes: estos envlan una senal cuando una persona ingresa al jardln. Se 
realiza un modelo simplificado de la situacion, asl que no se estudiaran los de- 
talles del hardware utilizado. Aqul es importante notar que los dos torniquetes 
son objetos que existen y se comportan en paralelo e independientemente: los 
eventos que generan no tienen un orden predecible. Es decir, que cuando se 
escriba el software no se sabe en que momento llegara cada visitante ni que 
torniquete utilizara. 

Se simulara un experimento en el que 20 visitantes ingresan por cada tor- 
niquete. Al final de la simulacion debera haber 40 visitantes contados. Una 
implementacion tentativa podrla ser la siguiente:'' 



1 


int cuenta; 




2 






3 
4 


proceso torniquetel () { 
int i ; 




5 


for (i=0;i<20;i++) 


{ 


6 


cuenta = 


cuenta 


7 

8 


} 

} 




9 






10 


proceso torniquete2 () { 




11 


int i ; 




12 


for (i=0; i<20; i++) 


{ 


13 


cuenta = 


cuenta 


14 


} 





^Se utiliza una version ficticia del lenguaje C para el ejemplo, evitando entrar en los detalles de 
sintaxis de un lenguaje concurrente. 
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15 ) 



16 



1 7 main ( ) { 

18 



cuenta = 0; 

/* Lanzar ambos procesos concurrentemente*/ 
concurrentemente { // 

torniquetel () ; 

torniquete2 () ; 

} 

/* Esperar a que ambos finalicen */ 



19 



20 



21 



22 



23 



24 



26 



25 



esperar (torniquetel) ; 
esperar (torniquete2) ; 



27 



printf ( "Cuenta : %d\n", cuenta); 



28 } 



Como se ve el problema es muy sencillo. Sin embargo, al intentar ejecutar 
repetidas veces ese programa muy de vez en cuando el resultado no tiene el 
valor 40. Si se modifica el programa para utilizar un solo torniquete, cuenta 
siempre tiene el valor correcto (20). 

^Que es lo que esta ocurriendo? La mayor parte de los lenguajes de progra- 
macion convierten cada instruccion en una serie mas o menos larga de opera- 
ciones de maquina (instrucciones ensamblador). De modo que una instruccion 
aparentemente simple, como cuenta = cuenta + 1 habitualmente implica 
varias operaciones de mas bajo nivel (las instrucciones de ejemplo correspon- 
den a arquitecturas Intel x86): 

LEER Leer cuenta desde la memoria (p. ej. mov $cuenta, %rax). 
INC Incrementar el registro (p. ej. add $ 1 , %rax). 

GUARDAR Guardar el resultado nuevamente en memoria (p. ej. mov%rax, 
$cuenta). 

En un sistema operativo multitarea cuando un proceso agota su porcion 
de tiempo de procesador (quantum) o detiene su ejecucion por otra razon, los 
valores almacenados en registros se preservan (junto con la informacion sobre 
el proceso) para poder restaurarlo cuando la ejecucion continue (de esta forma 
se provee la ilusion de la multitarea en sistemas de im solo niicleo). Asl, en el 
problema del jardln ornamental cada torniquete tiene su propia copia de los 
valores en los registros. Sin embargo, se supone que el resto de la memoria es 
compartida (en particular, se utiliza ese hecho para llevar la cuenta de personas 
que ingresan). 

Si se considera lo que ocurre cuando dos procesos (p. ej. torniquetel y 
torniquete2) ejecutan la instruccion cuenta = cuenta + 1 en un equi- 
po con un solo procesador, puede darse la siguiente secuencia de eventos. Se 
considera que cuenta esta inicialmente en 0. 
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1. cuenta = 0 

2. torniquetel: LEER (resiiltado: rax de pi = 0, cuenta = 0) 

3. torniquetel: INC (resultado: rax de pi = 1, cuenta = 0) 

4. torniquetel: GUARDAR (resiiltado: rax de pi = 1, cuenta = 1) 

5. El sistema operative decide cambiar de tarea, suspende torniquetel y 
continiia con torniquete2. 

6. torniquete2: LEER (resultado: rax de p2 = 1/ cuenta = 1) 

7. torniquete2: INC (resultado: rax de p2 = 2, cuenta = 1) 

8. torniquete2: GUARDAR (resultado: rax de p2 = 2, cuenta = 2) 

Se puede ver que ambos procesos realizaron sus instrucdones para incre- 
mentar el contador en 1 y el resiiltado final fue que la cuenta se incremento en 
dos ujnidades. 

Pero, tambien puede darse la siguiente secuencia de eventos durante la eje- 
cucion de estas instrucciones: 

1. cuenta = 0 

2. torniquetel: LEER (resultado: rax de pi = 0, cuenta = 0) 

3. torniquetel: INC (resultado: rax de pi = 1, cuenta = 0) 

4. El sistema operative decide cambiar de tarea, suspende torniquetel y 
continiia con torniquete2. 

5. torniquete2: LEER (resultado: rax de p2 = 1/ cuenta = 1) 

6. torniquete2: INC (resultado: rax de p2 = 2, cuenta = 1) 

7. torniquete2: GUARDAR (resultado: rax de p2 = 2, cuenta = 2) 

8. El sistema operative decide cambiar de tarea, suspende torniquete2 y 
continua con torniquetel. 

9. torniquetel: GUARDAR (resultado: rax de pi = 1, cuenta = 1) 

Nuevamente ambos procesos ejecutaron sus instrucciones para incrementar 
en 1 el contador. Sin embargo, jen este caso cuenta tiene el valor 1! A este 
problema tambien se lo conoce como problema de las actualizaciones multiples. 
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Esto parece muy especffico Si bien este analisis presenta aparentemente una 
problematica especifica al planteamiento en cuestionm es facil ver que la 
misma circustancia podria darse en un sistema de reserva de vuelos (p. 
ej.: puede que dos operadores vean un asiento vacio en su copia local de 
los asientos y ambos marquen el mismo asiento como ocupado) o con 
dos procesos que decidan cambiar simiiltaneamente datos en un archivo. 
AquI las operaciones ya no son necesariamente internas de la maqiiina. 

^Pero no es muy poco probable? For otro lado, uno podria pensar (con cier- 

ta cuota de razon) que la secuencia de eventos propuesta es muy poco 
probable: usuahnente un sistema operativo ejecuta miles de instruccio- 
nes antes de cambiar de un proceso a otro. De hecho, en la practica este 
problema es muy frecuentemente ignorado y los programas funcionan 
muy bien la mayoria de las veces. Esto permite ver una caracteristica im- 
portante de los programas concurrentes: es muy usual que un programa 
funcione perfectamente la mayor parte del tiempo, pero de vez en cuan- 
do puede fallar. Subsecuentes ejecudones con los mismos argumentos 
producen nuevamente el resultado correcto. Esto hace que los problemas 
de conciurrencia sean muy dificiles de detectar y mas aiin de corregir. Es 
importante (y mucho mas efectivo) realizar un buen diseno inicial de un 
programa concurrente en lugar de intentar arreglarlo cuando se detecta 
alguna falla. Tambien es interesante notar que dependiendo del sistema, 
puede ser que alguna de las instrucciones sea muy lenta, en el caso de un 
sistema de reserva de asientos de aviones, las operaciones pueden durar 
im tiempo importante (p. ej.: desde que el operador muestra los asientos 
disponibles hasta que el cliente lo elige) haciendo mucho mas probable 
que ocurra una secuencia no deseada. 

^Vale la pena preocuparse? A modo de ilustracion de la gravedad del pro- 
blema, estos son algunos valores para el resultado final de la variable 
cuenta cuando se ejecuta el programa anterior en Pascal-FC^: 25 29 31 
20 21 26 27 18 31 35. Notese que incluso uno de los valores es menor que 
20 (que es lo minimo que cuenta cada torniquete). Es un ejercicio intere- 
sante pensar que secuencia de eventos podria producir tal valor y cual es 
el mmimo valor posible. 

Pero tenemos muchos nucleos Otra cuestion que puede parecer artificiosa es 
que en el ejemplo hay un solo procesador o nucleo. Sin embargo, tener 
mas de un procesador no solo no soluciona el problema sino que lo em- 
peora: ahora las operaciones de lectura o escritura pueden ejecutarse di- 
rectamente en paralelo y aparecen nuevos problemas de coherencia de 
cache. En la siguiente discusion muchas veces se presupone que hay un 
solo procesador, sin que eso invalide la discusion para equipos miiltipro- 
cesadores. 

■*http: / / www-users.cs.york.ac.uk/bums/pf.htinl 
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Algunos conceptos de concurrencia 

Antes de abordar algimas posibles soluciones al problema, se presentan las 
definiciones de algunos conceptos importantes. 

Operacion atomica Manipulacion de datos que requiere la garantia de que se 
ejecutara come una sola unidad de ejecucion, o fallara completamente, 
sin resultados o estados parciales observables por otros procesos o el en- 
tomo. Esto no necesariamente implica que el sistema no retirara el flujo 
de ejecucion en medio de la operacion, sino que el efecto de que se le retire 
el flujo no Uevara a un comportamiento inconsistente. 

Condicion de carrera {Race condition) Categoria de errores de programacion 
que involucra a dos procesos que fallan al comunicarse su estado mutuo, 
llevando a resultados inconsistentes. Es uno de los problemas mas fre- 
cuentes y dificiles de depurar, y ociurre tlpicamente por no considerar la 
no atomicidad de una operacion 

Seccion (o region) critica El area de codigo que requiere ser protegida de acce- 
sos simultaneos donde se realiza la modificiacion de datos compartidos. 

Recurso compartido Un recurso al que se puede tener acceso desde mas de 
un proceso. En muchos escenarios esto es un variable en memoria (como 
cuenta en el jardln ornamental), pero podrian ser archivos, perifericos, 
etcetera. 

Dado que el sistema no tiene forma de saber cuales instrucciones (o areas 
del codigo) deben funcionar de forma atomica, el programador debe asegurar 
la atomicidad de forma expHcita, mediante la sincronizacion de los procesos. 
El sistema no debe permitir la ejecucion de parte de esa area en dos procesos 
de forma simultanea (solo puede haber \m proceso en la seccion crftica en un 
momento dado). 

■ que tiene que ver esto con el problema del jardm ornamental? 
En el problema hay claramente im recurso compartido que es la cuenta, 
por tanto, el codigo que modifica la cuenta constituye una seccion critica y 
la operacion cuenta = cuenta + 1 debe ser una operacion atomica. La 
secuencia de eventos que se mostro es una condicion de carrera: el segundo 
tomiquete presume un estado (cuenta = 0) que no es el mismo que 
conoce el torniquetel (cuenta = 1). 

Soluciones posibles (y no tanto) 

El planteamiento del problema del jardm ornamental busca llevar al lector a 
ir encontrando, mediante sucesivos refinamientos, los mecanismos principales 
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que se emplean para resolver -en general- los problemas que implican el acce- 
so concurrente a una seccion critica. Se presentan a continuacion los sucesivos 
intentos. 

Intento 1: No utilizar multitarea En este sencillo ejemplo una posible solu- 
cion es utilizar unicamente una entrada (o tomiquete). Esto podria ser 
una solucion en tanto que no haya mucha gente que haga cola para en- 
trar. Sin embargo, en un sistema analogo de reserva de pasajes aereos no 
parece tener mucho sentido que todos los pasajeros deban ir a Japon a 
sacar su pasaje. Por otro lado, ya deberlan ser claras las ventajas de la 
multitarea y el poseer distintos micleos. 

Intento 2: Suspender la multitarea durante la seccion critica Una version mas 
relajada de la altemativa anterior es suspender la multitarea durante la 
ejecucion de la seccion critica. Asl, un torniquete debera hacer: 

1 disableO; /* Suspender temporal las interrupciones */ 

2 cuenta = cuenta + 1; 

3 enable (); /* Habilitar nuevamente las Interrupciones */ 



Durante el lapso en el que las interrupciones estan suspendidas no pue- 
de haber un cambio de contexto pues el planificador depende de la in- 
terrupcion del reloj (salvo que el proceso realice una llamada bloqueante 
durante la region critica). 

Esta solucion puede resultar conveniente para sistemas sencillos, pero en 
un sistema multiusuario se torna rnusable por varios motivos: 

■ Permitir que un programa de usuario deshabilite las interrupciones 
en un sistema operativo de proposito general involucra im gran pro- 
blema de seguridad: cualquier usuario podria hacer un programa 
malicioso (o sencillamente erroneo) que deshabilite las interrupcio- 
nes y suspenda indefinidamente el resto del sistema. 

■ No funciona para sistemas distribuidos (como el sistema de reserva 
de pasajes aereos), ni siquiera para sistemas multinucleo o multipro- 
cesador, ya que las interrupciones se deshabilitan en un solo nucleo 
(si bien tambien es posible detener a los demas procesadores, repre- 
senta un costo demasiado alto). 

■ Expone detalles de hardware y podria provocar mal f uncionamiento 
de algun periferico si el procesamiento de la seccion critica es dema- 
siado largo. 

Intento 3: Utilizar una bandera Utilizar una bandera parece ser una solucion 
muy sencilla: mediante una variable de bandera se indica si hay un pro- 
ceso en la region critica: 
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1 


int bandera = 0 ; / * 0 


=> region critica libre, 1 => 




ocupada */ 




2 


int cuenta = 0 ; 




3 
4 


/* . . . */ 




5 


/* Torniquetel */ 




6 


/* .. . */ 




7 


if (bandera) wait; 




8 


/* Aqul bandera=0 */ 




9 


bandera =1; /* Inicio 


de la seccion critica */ 


10 


cuenta = cuenta + 1 ; 




11 


bandera =0; /* Fin de 


la seccion critica */ 



Sin embargo esto no funciona, ahora puede darse la siguiente secuencia 
de eventos: 



1. bandera==0; 

2. torniquete2: if (bandera) wait; 

3. Nuevo cambio de contexto 

4. torniquetel: if (bandera) wait; 

5. torniquetel: bandera = 1; 

6. torniquete2: bandera = 1; 

7. torniquete2: cuenta = cuenta + 1; 

8. torniquetel: cuenta = cuenta + 1; /* Ups, no se respe 
la regidn critica */ 

Pero notese que el problema aqui es que la bandera tambien es un recur- 
so compartido: lo unico que ha cambiado es que ahora la seccion critica 
esta en otro lugar. La solucion funcionarla si se pudiera garantizar que la 
secuencia de operaciones se realizara atomicamente: 

1 if (bandera) wait; I 

2 bandera =1 I 



Intento 4: Manejar la bandera con instrucciones atomicas Algunas arquitec- 
turas de computadoras permiten realizar determinadas operaciones sen- 
cillas (como actualizar una bandera) de forma atomica (p. ej.: VAX tiene 
la rnstruccion test_and_set y el 1386 tiene la instruccion INC. 

Usando esto, la solucion es: 



1 int bandera; /* 0 => desocupada */ 
2 

3 while (++bandera != 1) { 
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4 bandera — ; /* Debe generar "INC" */ 

5 } 

6 /* Seccion critica */ 

7 cuenta = cuenta + 1; 

8 

9 bandera — ; 



Esto funciona correctamente siempre que la operacion ++bandera sea ato- 
mica. Sin embargo, hay dos problemas a considerar: un proceso puede 
permanecer mucho tiempo repitiendo el ciclo: 

1 while (++bandera!=l) { 

2 bandera — ; 

3 } 



De hecho, si el sistema operative decide darle alta prioridad a este pro- 
ceso es posible que este un tiempo uifinito en este ciclo, impidiendo que 
otro proceso decremente la bandera. Y aun cuando el sistema operative 
decida cambiar de proceso en el siguiente tic de reloj, es evidente que se 
podrla aprovechar el procesador para hacer algo litil durante ese tiempo 
y que suspender el proceso de otra manera le da mas posibilidad a otros 
procesos para que cambien la bandera. A esto se lo conoce como espera 
activa o espera ocupada {busy waiting o spinlock) y es una situacion que se 
desea evitar. 

El otro problema tiene que ver con el hardware: determinadas arquitectu- 
ras no permiten instrucciones que lean y actualicen en una unica opera- 
cion una direccion de memoria (se requiere una operacion para leer y otra 
para escribir). En particular, ninguna arquitectura tipo RISC lo permite (p. 
ej.: SPARC, RS 6000, .. .). 

Intento 5: Utilizar turnos Una alternativa para evitar el problema de la actua- 
lizacion multiple a una bandera es utilizar turnos 

1 int turno =1; / * Inicialmente el turno es del proceso 1 */ 



Ahora el codigo del proceso 1 contendrla algo como: 



1 


while (turno 1= 1) { 




2 


esperarO; /* ^Otro proceso? */ 




3 


} 




4 


/* Seccion critica */ 




5 


cuenta = cuenta + 1; 




6 


turno = 2 ; 





Y el del proceso dos: 
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1 while (turno != 2) { 

2 esperar () ; 

3 } 

4 /* Seccion critica */ 

5 cuenta = cuenta + 1 ; 

6 turno = 1; 



Esto garantiza que no hay dos procesos en seccion critica. Pero notese 
que hacer esto equivale a tener un solo torniquete: solo podra haber una 
persona ingresando a la vez. . . o incluso peor, las personas deberan uti- 
lizar alternativamente los torniquetes. Asl que, si bien esto soluciona el 
problema de la actualizacion multiple, en realidad es una respuesta muy 
restrictiva: un proceso que no esta en la seccion critica puede obligar a 
que otro proceso espere mucho tiempo para uigresar a la seccion critica. 
De aqul en mas se buscaran soluciones en las que no ocurra esto. 

Intento 6: Indicar la intencion de entrar a la seccion critica Para paliar los efec- 
tos de la solucion anterior se puede rntentar indicar si el otro proceso 
tambien esta queriendo entrar en la seccion critica. El codigo serla: 



1 


int 


bl, b2; 


2 


/* 


. . . */ 


3 






4 


/* 


Proceso 1 : */ 


5 


/* 


... */ 


6 


bl 


= 1; 


7 


if 


(b2) { 


8 




esperar () ; 


9 


} 




10 


/* 


Seccion critica */ 


11 


cuenta = cuenta + 1 ; 


12 


bl 


= 0; 


13 


/* 


. . . */ 


14 


/* 


Proceso 2: */ 


15 


/* 


... */ 


16 


b2 


= 1; 


17 


if 


(bl) { 


18 




esperar () ; 


19 


} 




20 


/* 


Seccion critica */ 


21 


cuenta = cuenta + 1; 


22 


b2 


= 0; 


23 


/* 


. . . */ 



Nuevamente aqul esta garantizado que no puede haber dos procesos en 
la region critica, pero este enfoque sufre de un problema grave: ambos 



3.3. CONCURRENCIA 



85 



pueden bloquearse mutuamente (si el proceso 1 coloca su bandera en 
1 y luego se cambia el control al proceso 2, el cual tambien colocara su 
bandera en 1). 

Una solucion: el algoritmo de Peterson 

La primera solucion a este problema fue propuesta por el matematico Theo- 
dorus Dekker en 1957. Sin embargo su explicacion es bastante extensa (aunque 
perfectamente comprensible). Se presentara la solucion planteada por Peterson 
unos cuantos anos mas tarde, en 1970. 

La solucion esta basada en una combinacion de los intentos anteriores: utili- 
zar banderas para indicar que proceso puede entrar, pero ademas usa un tumo 
para desempatar en caso de que ambos procesos busquen entrar a la vez. En 
cierto modo es un algoritmo amable: si un proceso detecta que el otro fue el 
primero en actualizar el turno, entonces lo deja pasar: 

1 int bl, b2; 

2 int quien; 

3 

4 / * Proceso 1 : */ 

5 ... 

6 bl=l; 

7 quien=2; 

8 if ( b2 && (quien==2)) { 

9 esperar () ; 

10 } 

11 /* Seccion crltica */ 

12 cuenta = cuenta + 1; 

13 bl=0; 

14 

15 /* Proceso 2: */ 

16 ... 

17 b2=l; 

18 quien=l; 

19 if ( bl && quien==l) { 

20 esperar () ; 

21 } 

22 /* Seccion crltica */ 

23 cuenta = cuenta + 1 ; 

24 bl=0; 



Cabe apuntar las siguientes notas sobre la solucion de Peterson: 

Espera activa La solucion presentada mantiene todavla el problema de la es- 
pera activa (tambien llamados spinlocks): im proceso puede consumir mu- 
cho tiempo de procesador solo para esperar que otro proceso cambie ima 
bandera lo cual, en un sistema con manejo de prioridades, puede resultar 
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danino para el desempeno global. Una forma de mitigar los efectos es 
forzar (o sugerir) cambios de contexto en esos puntos mediante una pri- 
mitiva del lenguaje o del sistema operative (p. ej.: sleep o yield), pero 
debe resultar claro que de ninguna forma es una solucion general. For 
esta razon los sistemas operatives o lenguajes suelen proveer algiina abs- 
tiraccion para soportar expHcitamente operadones atomicas o darle una 
solucion mas elegante al problema. Se veran algunas de esas abstraccio- 
nes mas adelante. 

Para mayores detalles acerca de las razones, ventajas y desventajas del 
uso de spinlocks en sistemas operatives reales, referirse a Spin Locks & 
Other Forms of Mutual Exclusion (Theodore F. Baker 2010) 

Solucion para mas procesos El algoritmo de Feterson sirve linicamente cuan- 
do hay dos procesos que compiten para acceder a una region critica. ^Que 
se puede hacer si hay mas de dos entradas al jardin, o si hay mas de dos 
puntos de venta de pasajes aereos? La solucion a este problema mas ge- 
neral fue propuesta por Dijkstia en 1968 y posteriormente Eisenberg y 
McGuire en 1972 y Lamport en 1974 presentaron distintas soluciones. 

La mas ampliamente utilizada y sencilla de entender es la propuesta por 
Lamport, tambien conocida como el algoritmo de la panaderia por su seme- 
janza con el sistema de turnos utilizado para atender a los clientes en una 
panaderia. 

Solucion para equipos multiprocesadores Esta solucion (y tambien la de Lam- 
port y todos los autores mencionadas hasta ahora) falla en equipos mul- 
tiprocesadores, pues aparecen problemas de coherencia de cache. Se ne- 
cesitan precauciones especiales en eqmpos con mas de un procesador. 

3.3.3. Mecanismos de sincronizacion 

En la presente seccion se enumeran los principales mecanismos que pueden 
emplearse para programar considerando a la concurrencia: candados, semafo- 
ros y variables de condicion. 

Regiones de exlcusion mutua: candados o mutexes 

Una de las alternativas que suele ofrecer un lenguaje concurrente o sistema 
operative para evitar la espera activa a la que obliga el algoritmo de Feterson (o 
similiares) se llama mutex o candado (lock). 

La palabra mutex nace de la frecuencia con que se habla de las regiones de 
exclusion mutua {mutual exclusion). Es im mecanismo que asegura que cierta 
region del codigo sera ejecutada como si fuera atomica. 

Hay que tener en cuenta que un mutex no implica que el codigo no se va a 
interrumpir mientras se esta dentio de esta region — eso seria muy peligroso. 
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3 

Tiempo 



Figura 3.5: Sincronizacion: la exclusion de las secciones crtticas entre varios proce- 
sos se protegen por medio de regiones de exclusion mutua. La figura ilustra varios 
procesos que requieren de una misma seccion critica; las flechas punteadas repre- 
sentan el tiempo que un proceso esta a la espera de que otro libere el paso para 
dicha seccion, y las punteadas verticales indican la transferencia del candado. 



dado que permitiria que el sistema operative pierda el control del planificador, 
volviendo (para propositos practicos) a un esquema de multitarea cooperativa. 
El mutex es un mecanismo de prevencion, que mantiene en espera a cualquier hilo 
o proceso que quiera entrar a la seccion critica protegida por el mutex, retenien- 
dolo antes de entrar a esta hasta que el proceso que la esta ejecutando saiga de 
ella. Si no hay ningun hilo o proceso en dicha seccion critica (o cuando un hilo 
sale de ella), uno solo de los que esperan podra ingresar. 

Como se vio en el ejemplo anterior, para que un mutex sea efectivo tiene 
que ser implementado mediante una primitiva a un nivel inferior,^ implicando 
al planificador. 

El problema de la actualizacion miiltiple que surge en el caso de la venta de 
pasajes aereos podria reescribirse de la siguiente manera empleando un mutex: 

1 my ($proximo_asiento : shared, $capaciclad : shared) ; 

2 $capacidad = 40; 

3 

4 sub asigna_asiento { 

5 lock ($proximo_asiento) ; 

6 if ($proximo_asiento < $capacidad) { 

7 $asignado = $proximo_asiento; 

8 $proximo_asiento += 1; 

9 print "Asiento asignado: $asignado\n" ; 
10 } else { 

^^Que significa inferior? Las Uamadas de sincronizacion entre hilos deben implementarse por 
lo menos en el nivel del proceso que los contiene; aquellas que se realizan entre procesos indepen- 
dientes, deben implementarse en el nivel del sistema operativo. Debe haber un agente mas abajo en 
niveles de abstraccion, en control real del equipo de computo, ofreciendo estas operaciones. 
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12 



11 



print "No hay asientos disponibles\n" ; 
return 1 ; 



14 



13 



} 

return 0 ; 



15 } 



Se debe tener en cuenta que en este caso se utiliza una implementacion de 
hilos, esto hace que la solucion sea dependiente del lenguaje especifico de im- 
plementacion, en este caso Perl. Al ser $proximo_as iento una variable com- 
partida tiene algunas propiedades adicionales, en este caso, la de poder operar 
como un mutex. La implementacion en Perl resulta muy limpia, dado que evita 
el uso de un candado expllcito — se podrla leer la llnea cinco como exclusion 
mutua sobre $proximo_asiento. 

En la implementacion de hilos de Perl, la funcion lock ( ) utiliza un mutex 
delimitado por el dmbito lexico de su rnvocacion: el area de exclusion mutua 
abarca desde la Irnea cinco en que es invocada hasta la 15 en que termina el 
bloque en que se invoco. 

Un area de exclusion mutua debe: 

Ser minima Debe ser tan carta como sea posible, para evitar que otros hilos que- 
den bloqueados fuera del area crltica. Si bien en este ejemplo es dema- 
siado simple, si se hiciera cualquier llamada a otra funcion (o al sistema) 
estando dentro de un area de exclusion mutua, se detendrla la ejecucion 
de todos los demas hilos por mucho mas tiempo del necesario. 

Ser completa Se debe analizar bien cual es el area a proteger y no arries- 
garse a proteger de menos. En este ejemplo, se podrla haber puesto 
lock ($asignado) dentro del if, dado que solo dentro de su evalua- 
cion positiva se modifica la variable $proxiino_asiento. Sin embargo, 
si la ejecucion de un hilo se interrumpiera entre las llneas siete y ocho, la 
condicion del i f se podrla evaluar incorrectamente. 

Como comparacion, una rutina equivalente escrita en Bash (entre proce- 
sos independientes y utilizando a los archivos /tmp/proximo_as iento y 
/etc/ capacidad como un mecanismo para compartir datos) serla: 

1 asigna_asiento 0 { 

2 lockfile /tmp/asigna_asiento . lock 

3 PROX=$ (cat /tmp/proximo_asiento | | echo 0) 

4 CAP=$(cat /etc/capacidad || echo 40) 

5 if [ $PROX -It $CAP ] 

6 then 

7 ASIG=$PROX 

8 echo $(($PR0X+1)) > /tmp/proximo_asiento 

9 echo "Asiento asignado : $ASIG" 
10 else 



3.3. CONCURRENCIA 



89 



11 



12 



echo "No hay asientos disponibles 
return 1 ; 



II 



14 



13 



fi 

rm -f /tmp/asigna_asiento . lock 



15 } 



Cabe mencionar que lockfilenoes una funcion implementada en Bash, 
sino que envuelve a una llamada al sistema. El sistema operative garantiza que 
la verificacion y creacion de este candado se efectuara de forma atomica. 

Un mutex es, pues, una herramienta muy sencilla, y podria verse como la 
pieza basica para la sincronizacion entre procesos. Lo fundamental para em- 
plearlos es identificar las regiones criticas del codigo, y proteger el acceso con 
un mecanismo apto de sincronizacion, que garantice atomicidad. 

Semaforos 

La interfaz ofrecida por los mutexes es muy sencilla, pero no permite resol- 
ver algunos problemas de sincronizacion. Edsger Dijkstra, en 1968, propuso los 
semaforos.^ 

Un semaforo es una variable de tipo entero que tiene definida la siguiente 
interfaz: 

Inicializacion Se puede inicializar el semaforo a cualquier valor entero, pe- 
ro despues de esto, su valor no puede ya ser leldo. Un semaforo es una 
estructura abstracta, y su valor es tomado como opaco (invisible) al progra- 
mador. 

Decrementar Cuando un hilo decrementa el semaforo, si el valor es negativo, 
el hilo se hloquea y no puede continuar hasta que otro hilo incremente el 
semaforo. Segun la implementacion, esta operacion puede denominarse 
wait, down, acquire o incluso P (por ser la inicial de proberen te verlagen, 
intentar decrementar en holandes, del planteamiento original en el artlculo 
de Dijkstra). 

Incrementar Cuando un hilo rncrementa el semaforo, si hay hilos esperando, 
uno de ellos es despertado. Los nombres que recibe esta operacion son 

signal, up, release, post o V (de verhogen, incrementar). 

La interfaz de hilos POSIX (pthreads) presenta esas primitivas con la si- 
guiente definicion: 

1 int sem_init (sem_t *sem, int pshared, unsigned int value) ; 

2 int sem__post (sem_t *sem) ; 

*E1 simil presentado por Dijkstra no es del semaforo vial, con una luz roja y una luz verde (dicho 
esquema se asemeja al del mutex). La referenda es a la del semaforo de tren, que permite el paso 
estando arriba, e indica espera estando ahajo. 
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3 int sem_wait (sem_t *sem) ; 

4 int sem_trywait (sem_t *sem) ; 




La variable p shared indica si el semaforo puede ser compartido entre pro- 
cesos o unicamente entre hilos. sem_trywait extiende la intefaz sugerida por 
Dijkstra: verifica si el semaforo puede ser decrementado y, en caso de que no, 
en vez de bloquearse, indica al proceso que no puede continuar El proceso 
debe tener la logica necesaria para no entrar en las secciones crlticas (p. ej., 
rntentar otra estrategia) en ese caso. 

sem_trywait se sale de la definicion clasica de semaforo, por lo que no se 
considera en esta seccion. 

Un semaforo permite la implementacion de varios patrones, entre los cuales 
se mencionaran los siguientes: 

Senalizar Un hilo debe informar a otro que cierta condicion esta ya cumplida 
— ^por ejemplo, un hilo prepara una conexion en red mientras que otro 
calcula lo que tiene que enviar. No se puede arriesgar a comenzar a enviar 
antes de que la conexion este lista. Se inicializa el semaforo a 0, y: 

1 # Antes de lanzar los hilos 

2 senal = Semaphore ( 0 ) 

3 

4 def envia_datos ( ) : 

5 calcula_datos 0 

6 senal . acquire 0 

7 envia_por_red ( ) 

8 

9 def prepara_conexion ( ) : 

1 0 crea_conexion ( ) 

11 senal . release ( ) 



No importa si prepara_conexion ( ) termina primero — en el momen- 
to en que termine, senal valdra 1 y envia_datos ( ) podra proceder. 

Rendezvous As! se denomrna en trances (y ha sido adoptado al ingles) a que- 
dar en una cita. Este patron busca que dos hilos se esperen mutuamente 
en cierto punto para continuar en conjunto — por ejemplo, en una apli- 
cacion GUI, un hilo prepara la interfaz grafica y actualiza sus eventos 
mientras otro efectua calculos para mostrar. Se desea presentar al usua- 
rio la simulacion desde el principio, asi que no debe empezar a calcular 
antes de que el GUI este listo, pero preparar los datos del calculo toma 
tiempo, y no se quiere esperar doblemente. Para esto, se unplementan 
dos semaforos senalizandose mutuamente: 



1 guiListo = Semaphore (0) 

2 calculoListo = Semaphore (0) 
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3 

4 threading. Thread (target=maneja_gui, args= []). start () 

5 threading. Thread (target=maneja_calculo, args= []). start () 

6 

7 def mane ja_gui 0 : 

8 inicializa_gui ( ) 

9 guiListo. release () 

10 calculoListo. acquire 0 

1 1 recibe_eventos ( ) 

12 

13 def mane ja_calculo () : 

14 inicializa_datos () 

15 calculoListo. release 0 

16 guiListo . acquire () 

17 procesa_calculo ( ) 



Mutex El uso de un semaforo inicializado a uno puede implementar facilmen- 
te un mutex. En Python: 

1 mutex = Semaphore (1) 

2 # . . . Inicializar estado y lanzar hilos 

3 mutex . acquire ( ) 

4 # Aqul se esta en la region de exclusion mutua 

5 X = X + 1 

6 mutex . release ( ) 

7 # Continua la ejecucion paralela 



Multiplex Permite la entrada de no mas de n procesos a la region crltica. Si se 
lo ve como una generalizacion del mutex, basta con inicializar al semaforo 
al niimero maximo de procesos deseado. 

Su construccion es identica a la de un mutex, pero es inicializado al niime- 
ro de procesos que se quiere permitir que ejecuten de forma simultanea. 

Torniquete Una construccion que por si sola no hace mucho, pero resulta litil 
para patrones posteriores. Esta construccion garantiza que un grupo de 
hilos o procesos pasa por un punto determinado de uno en uno (incluso en 
un ambiente multiprocesador): 



1 


torniquete = Semaphore (0) 




2 


# (...) 




3 


if alguna_condicion ( ) : 




4 


torniquete . release ( ) 




5 


# (.. .) 




6 


torniquete . acquire ( ) 




7 


torniquete . release ( ) 
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En este caso, se ve primero una senalizacion que hace que todos los proce- 
sos esperen frente al torniquete hasta que alguno marque que alguna_- 
condicion ( ) se ha cumplido y libere el paso. Posteriormente, los pro- 
cesos que esperan pasaran ordenadamente por el torniquete. 

El torniquete por si solo no es tan util, pero su funcion se hara clara a 
continuacion. 

Apagador Cuando se tiene una situacion de exclusion categorica (basada en ca- 
tegorlas y no en procesos individuales — ^varios procesos de la misma 
categorla pueden entrar a la seccion crltica, pero procesos de dos cate- 
gorlas distintas deben tenerlo prohibido), un apagador permite evitar la 
inanicion de una de las categorlas ante un flujo constante de procesos de 
la otra. 

El apagador usa, como uno de sus componentes, un torniquete. Para ver 
una implementacion ejemplo de un apagador, referirse a la solucion pre- 
sentada para el problema de los lectores y los escritores (seccion 3.3.6). 

Barrera Una barrera es una generalizacion de rendezvous que permite la sin- 
cronizacion entre varios hilos (no solo dos), y no requiere que el papel de 
cada uno de los hilos sea distinto. 

Esta construccion busca que ninguno de los hilos continue ejecutando 
hasta que todos hayan Uegado a im punto dado. 

Para implementar una barrera, es necesario que esta guarde algo de in- 
formacion adicional ademas del semaforo, particularmente, el numero de 
hilos que se han lanzado (para esperarlos a todos). Esta sera una variable 
compartida y, por tanto, requiere de un mutex. La rnicializacion (que se 
ejecuta antes de rniciar los hilos) sera: 



1 


require random 




2 


n = random. randint (1, 10) # Numero de hilos 




3 


cuenta = 0 




4 


mutex = Semaphore ( 1 ) 




5 


barrera = Semaphore (0) 





Ahora, suponiendo que todos los hilos tienen que realizar, por separa- 
do, la rnicializacion de su estado, y nrnguno de ellos debe comenzar el 
procesamiento hasta que todos hayan efectuado su inicializacion: 

1 inicializa_estado 0 

2 

3 mutex . acquire ( ) 

4 cuenta = cuenta + 1 

5 mutex . release () 

6 

7 if cuenta == n: 
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8 barrera. release 0 

9 

10 barrera . acquire ( ) 

11 barrera. release 0 

12 

13 procesamiento 0 



Las barreras son una construccion suficientemente litil como para que sea 
comun encontrarlas "prefabricadas". En los hilos POSIX (pthreads), por 
ejemplo, la interfaz basica es: 



1 


int 


pthread_barrier_ 


_init (pthread_barrier_t *barrier, 


2 






const pthread_barrierattr_t 
★restrict attr, 


3 






unsigned count) ; 


4 


int 


pthread_barrier_ 


_wait (pthread_barrier_t *barrier) ; 


5 


int 


pthread_barrier_ 


.destroy (pthread_barrier_t *barrier) ; 



Cola Se emplea cuando se tienen dos clases de hilos que deben proceder en 
pares. Este patron es a veces referido como baile de salon: para que una 
pareja baile, hace falta que haya un lider y un seguidor. Cuando llega una 
persona al salon, verifica si hay uno de la otra clase esperando bailar. 
En caso de haberlo, bailan, y en caso contrario, espera a que llegue su 
contraparte. 



El codigo para implementar esto es muy simple: 



1 


colaLideres = Semaphore (0) 




2 


colaSeguidores = Semaphore (0) 




3 


# (.. .) 




4 


def lider 0 : 




5 


colaSeguidores . release ( ) 




6 


colaLideres . acquire ( ) 




7 


bailaO 




8 


def seguidor 0 : 




9 


colaLideres . release () 




10 


colaSeguidores . acquire ( ) 




11 


bailaO 





El patron debe resultar ya familiar: es un rendezvous. La distincion es me- 
ramente semantica: en el rendezvous se necesitan dos hilos expllcitamente, 
aqul se habla de dos clases de hilos. 

Sobre este patron base se pueden refinar muchos comportamientos. Por 
ejemplo, asegurar que solo una pareja este bailando al mismo tiempo, 
o asegurar que los hilos en espera vayan bailando en el orden en que 
llegaron. 
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Variables de condicion 

Las variables de condicion presentan una extension sobre el comportamien- 
to de los mutexes, buscando darles la "inteligencia" de responder ante determi- 
nados eventos. Una variable de condicion siempre opera en conjunto con un 
mutex, y en algunas implementaciones es necesario indicar cual sera dicho mu- 
tex desde la misma inicializacion del objeto7 

Una variable de condicion presenta las siguientes operaciones: 

Espera Se le indica una condicion y un mutex, el cual tiene que haber sido ya 
adquirido. Esta operacion libera al mutex, y se bloquea hasta recibir una 
notificacion de otro hilo o proceso. Una vez que la notificacion es recibida, 
y antes de devolver la ejecucion al hilo, re-adquiere el mutex. 

Espera medida Tiene una semantica igual a la de la espera, pero recibe un ar- 
gumento adicional, indicando el tiempo de expiracion. Si pasado el tiem- 
po de expiracion no ha sido notificado, despierta al hilo regresandole un 
error (y sin re-adquirir el mutex). 

Senaliza Requiere que el mutex ya haya sido adquirido. Despierta (senaliza) a 
uno o mas hilos (algunas implementaciones permiten indicar como argu- 
mento a cuantos hilos) de los que estan bloqueados en la espera asociada. 
No libera el mutex — esto significa que el flujo de ejecucion se mantiene en 
el invocante, quien tiene que salir de su seccion crftica (entregar el mutex) 
antes de que otro de los hilos continue ejecutando. 

Senaliza a todos Despierta a todos los hilos que esten esperando esta condicion. 



La interfaz de hilos POSIX (pthreads) presenta la siguiente definicion: 



1 


pthread_cond_t cond = PTHREAD_COND_INITIALIZER; 


2 


int 


pthread_cond_init (pthread_cond_t *cond, pthread_condattr_t 






*cond_attr) ; 


3 


int 


pthread_cond_signal (pthread_cond_t *cond) ; 


4 


int 


pthread_cond_broadcast (pthread_cond_t *cond) ; 


5 


int 


pthread_cond_wait (pthread_cond_t *cond, pthread_mutex_t 






*mutex) ; 


6 


int 


pthread_cond_timedwait (pthread_cond_t *cond, 






pthread_mutex_t *mutex, const struct timespec *abstime) ; 


7 


int 


pthread_cond_destroy (pthread_cond_t *cond) ; 



^Mientras que otras implementaciones permiten que se declaren por separado, pero siempre 
que se invoca a una variable de condicion, debe indicarsele que mutex estara empleando. 
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3.3.4. Problema productor-consumidor 
Planteamiento 

En un entorno multihilos es comun que haya una division de tareas tipo 
Imea de ensamblado, que se puede generalizar a que un grupo de hilos van pro- 
duciendo ciertas estructuras, a ser consumidas por otro grupo. 

Un ejemplo de este problema puede ser un programa orientado a eventos, en 
que eventos de distinta naturaleza pueden producirse, y causan que se disparen 
los mecanismos que los puedan atender Los eventos pueden apilarse en un buf- 
fer que sera procesado por los hilos encargados conforme se vayan liber ando. 
Esto impone ciertos requisitos, como: 

■ Debido a que el buffer es un recurso compartido por los hilos, agregar 
o retirar un elemento del buffer tiene que ser hecho de forma atomica. 
Si mas de un proceso intentara hacerlo al mismo tiempo, se correrla el 
riesgo de que se corrompan los datos. 

■ Si un consumidor esta listo y el buffer esta vacio, debe bloquearse (jno 
realizar espera activa!) hasta que un productor genere un elemento. 

Si no se tiene en cuenta la sincronizacion, el codigo serla tan simple como 
el siguiente: 

1 import threading 

2 buffer = [] 

3 threading. Thread (target=productor, args= [] ) .start () 

4 threading . Thread (target=consumidor , args= [ ] ) . start ( ) 

5 

6 def productor () : 

7 while True : 

8 event = genera_evento ( ) 

9 buff er . append (event) 

10 

11 def consumidor ( ) : 

12 while True: 

13 event = buffer.popO 

14 procesa (event) 



Pero el acceso a buf f er no esta protegido para garantizar la exclusion mu- 
tua, y podrla quedar en un estado inconsistente si append ( ) y pop ( ) intentan 
manipular sus estructuras al mismo tiempo. Ademas, si bien en este ejemplo 
se asumio que hay solo un hilo productor y solo uno consumidor, se puede ex- 
tender el programa para que haya varios hilos en cualquiera de estos papeles. 

En este caso, la variable event no requiere de proteccion, dado que es local 
a cada hilo. 
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Solucion 

Para resolver este problema se usaran dos semaforos: mutex, que protege el 
acceso a la seccion critica, y elementos. El valor almacenado en elementos 
indica, cuando es positivo, cuantos eventos pendientes hay por procesar, y 
cuando es negativo, cuantos consumidores estan listos y esperando un evento. 

Una solucion a este problema puede ser: 

1 import threading 

2 mutex = threading. Semaphore (1) 

3 elementos = threading . Semaphore ( 0 ) 

4 buffer = [] 

5 threading. Thread (target=productor, args= []). start ( ) 

6 threading. Thread (target=consumidor, args= []). start ( ) 

7 

8 def productorO : 



9 while True : 

1 0 event = genera_evento ( ) 

11 mutex . acquire () 

12 buffer. append (event) 

13 mutex . release () 

14 elementos . release 0 

15 

16 def consumidorO : 

I 7 while True : 

18 elementos . acquire 0 

19 mutex . acquire () 

20 event = buffer.popO 

21 mutex. release () 

22 event .process () 



Se puede ver que la misma construccion, un semaforo, es utilizada de for- 
ma muy distinta por mutex y elementos. mutex implementa una exclusion 
mutua clasica, delimitando tanto como es posible (a una sola llnea en este ca- 
so) al area critica, y siempre apareando un acquire { ) con un release ( ) . 
elementos, en cambio, es empleado como un verdadero semaforo: como una 
estructura para la sincronizacion. Solo los hilos productores incrementan (suel- 
tan) el semaforo, y solo los consumidores lo decrementan (adquieren). Esto es, 
ambos semaforos comunican al planificador cuando es posible despertar a algiin 
consumidor. 

Si se supone que genera_evento ( ) es eficiente y no utiliza espera activa, 
esta implementacion es optima: deja en manos del planificador toda la espera 
necesaria, y no desperdicia recursos de computo esperando a que el siguiente 
elemento este listo. 

Como nota al pie, la semantica del modulo threading de Python rncluye 
la declaracion de contexto with. Todo objeto de threading que implemente 
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acquire ( ) y release ( ) puede ser envuelto en un bloque with, aumentan- 
do la legibilidad y con exactamente la misma semantica; no se utilize en este 
ejemplo para ilustrar el uso tradicional de los semaforos para implementar re- 
giones de exclusion mutua, sin embargo y solo para concluir con el ejemplo, la 
funcion consumidor ( ) final podrla escribirse asl, y ser semanticamente iden- 
tical 



1 def consumidor 0 : 

2 while True : 

3 elementos . acquire ( ) 

4 with mutex : 

5 event = buffer.popO 

6 event .process 0 



A pesar de ser mas clara, no se empleara en este texto esta notacion por 
dos razones. La primera es para mantener la conciencia de la semantica de las 
operaciones acquireO yrelease(),yla segunda es mantener la consisten- 
cia entre las distrntas implementaciones, ya que se encontraran varios casos en 
que no es el mismo hilo el que adquiere un semaforo y el que lo libera (esto es, 
los semaforos no siempre son empleados como mutexes). 



3.3.5. Bloqueos mutuos e inanicion 

Cuando hay concurrencia, ademas de asegurar la atomicidad de ciertas 
operaciones, es necesario evitar dos problemas que son consecuencia natural 
de la existencia de la asignacion de recursos de forma exclusiva: 

Bloqueo mutuo (o interbloqueo; en ingles, deadlock) Situacion que ocurre cuan- 
do dos o mas procesos poseen determinados recursos, y cada uno queda 
detenido, a la espera de alguno de los que tiene el otro. El sistema puede 
seguir operando normalmente, pero nuiguno de los procesos uivolucra- 
dos podran avanzar. 

Inanicion {resource starvation) Situacion en que un proceso no puede avanzar 
en su ejecucion dado que necesita recursos que estan (alternativamente) 
asignados a otros procesos. 

El que se presenten estos conceptos aqul no significa que estan exclusiva- 
mente relacionados con este tema: son conceptos que se enfrentan una y otra 
vez al hablar de asignacion exclusiva de recursos — tematica recurrente en el 
campo de los sistemas operatives. 
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3.3.6. Problema de los lectores y los escritores 
Planteamiento 

Una estructura de datos puede ser accedida simultaneamente por muchos 
procesos lectores, pero si alguno esta escribiendo, se debe evitar que cualquier 
otro lea (dado que podria encontrarse con los datos en un estado inconsistente). 
Los requisitos de sincronizacion son 

■ Cualquier cantidad de lectores puede estar leyendo al mismo tiempo. 

■ Los escritores deben tener acceso exclusivo a la seccion crltica. 

■ En pos de un comportamiento mas justo: se debe evitar que un rnflujo 
constante de procesos lectores dejen a im escritor en situacion de inani- 
cion. 



Discusion 

Este problema puede ser generalizado como una exclusion mutua categorica: 
se debe separar el uso de un recurso segun la categorla del proceso. La presen- 
cia de un proceso en la seccion crltica no lleva a la exclusion de otros, pero si 
hay categorias de procesos que tienen distrntas reglas — para los escritores si 
hace falta una exclusion mutua completa. 



Primera aproximacion 

Un primer acercamiento a este problema permite una resolucion libre de 
bloqueos mutuos, empleando solo tres estructuras globales: un contador que 
indica cuantos lectores hay en la seccion crltica, un mutex protegiendo a dicho 
contador, y otro mutex rndicando que no hay lectores ni escritores accediendo 
al buffer (o cuarto). Se implementan los mutexes con semaforos. 



1 import threading 

2 lectores = 0 

3 mutex = threading. Semaphore (1) 

4 cuarto_vacio = threading. Semaphore (1) 

5 

6 def escritor (): 

7 cuarto_vacio . acquire ( ) 

8 escribe 0 

9 cuarto_vacio . release ( ) 

10 

11 def lector 0 : 

12 mutex . acquire () 

13 lectores = lectores + 1 

14 if lectores == 1: 

15 cuarto_vacio. acquire 0 
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16 mutex. release () 

17 

18 lee() 

19 

20 mutex. acquire () 

21 lectores = lectores - 1 

22 if lectores == 0: 

23 cuarto_vacio . release ( ) 

24 mutex . release ( ) 



El semaforo cuarto_vacio sigue un patron visto antes llamado apagador. 
El escritor utiliza al apagador como a cualquier mutex: lo utiliza para rodear a 
su seccion critica. El lector, sin embargo, lo emplea de otra manera. Lo primero 
que hace es verificar si la luz estd prendida, esto es, si hay algiin otro lector en el 
cuarto (si lectores es igual a 1). Si es el primer lector en entrar, prende la luz 
adquiriendo cuarto_vacio (lo cual evitara que un escritor entre). Cualquier 
cantidad de lectores puede entrar, actualizando su numero. Cuando el ultimo 
sale (lectores es igual a 0), apaga la luz. 

El problema con esta implementacion es que un flujo constante de lecto- 
res puede llevar a la inanicion de un escritor, que esta pacientemente parado 
esperando a que alguien apague la luz. 



Solucion 

Para evitar esta condicion de inanicion, se puede agregar un torniquete evi- 
tando que lectores adicionales se cuelen antes del escritor. Reescribiendo: 

1 import threading 

2 lectores = 0 

3 mutex = threading. Semaphore (1) 

4 cuarto_vacio = threading . Semaphore ( 1 ) 

5 torniquete = threading. Semaphore (1) 

6 

7 def escritor (): 

8 torniquete . acquire 0 

9 cuarto_vacio. acquire 0 

10 escribe 0 

11 cuarto_vacio. release 0 

12 torniquete . release () 
13 

14 def lector 0 : 

15 global lectores 

16 torniquete. acquire () 

17 torniquete . release () 

18 

19 mutex. acquire 0 

20 lectores = lectores + 1 
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21 if lectores == 1: 

22 cuarto_vacio. acquire 0 

23 mutex . release () 

24 

25 lee() 

26 

21 mutex . acquire 0 

28 lectores = lectores - 1 

29 if lectores == 0: 

30 cuarto_vacio . release ( ) 

31 mutex . release () 



En la implementacion de los escritores, esto puede parecer iniitil: unica- 
mente se agrego un mutex redundante alrededor de lo que ya se tenia. Sin 
embargo, al hacer que el lector pase por un torniquete antes de actualizar 
lectores, obligando a que se mantenga encendida la luz, se lo fuerza a espe- 
rar a que el escritor suelte este mutex exterior Nuevamente se puede ver como 
la misma estructura es tratada de dos diferentes maneras: para el lector es un 
torniquete, y para el escritor es un mutex. 

3.3.7. La cena de los filosofos 
Planteamiento 

Cinco filosofos se dan cita para comer arroz en una mesa redonda. En ella, 
cada uno se sienta f rente a im plato. A su derecha, tiene un palito chrno, y a su 
izquierda tiene otro. 

Los filosofos solo saben pensar ( ) y comer ( ) . Cada uno de ellos va a 
pensar ( ) un tiempo arbitrario, hasta que le da hambre. El hambre es mala 
consejera, por lo que intenta comer ( ) . Los requisitos son: 

■ Solo un filosofo puede sostener determinado palito a la vez, esto es, los 
palitos son recursos de acceso exclusivo. 

■ Debe ser imposible que un filosofo muera de inanicion estando a la espe- 
ra de un palito. 

■ Debe ser imposible que se presente un bloqueo mutuo. 

■ Debe ser posible que mas de un filosofo pueda comer al mismo tiempo. 

Discusion 

En este caso, el peligro no es, como en el ejemplo anterior, que una estruc- 
tura de datos sea sobreescrita por ser accedida por dos hilos al mismo tiempo, 
sino que se presenten situaciones en el curso normal de la operacion que Ueven 
a un bloqueo mutuo. 
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A diferencia del caso antes descrito, ahora se utilizaran los semaforos, no 
como una herramienta para indicar al planificador cuando despertar a uno de 
los hilos, sino como una herramienta de comimicacion entre los propios hilos. 

Primer acercamiento 

Los palillos pueden representarse como un arreglo de semaforos, asegu- 
rando la exclusion mutua (esto es, solo un filosofo puede sostener un palillo al 
mismo tiempo), pero eso no evita el bloqueo mutuo. Por ejemplo, si la solucion 
fuera: 



1 import threading 

2 num = 5 

3 palillos = [threading . Semaphore (1) for i in range (num) ] 

4 filosofos = [threading. Thread (target=filosofo, 

args= [i] ). start () for i in range (num) ] 

5 

6 def filosofo (id) : 

7 while True : 

8 piensa(id) 

9 levanta_palillos (id) 

10 come (id) 

11 suelta_palillos (id) 
12 

13 def piensa(id) : 

14 #(...) 

15 print "%d - Tengo hambre..." % id 

16 

17 def levanta__palillos (id) : 

18 palillos [ (id+1) % num] . acquire () 

19 print "%d - Tengo el palillo derecho" % id 

20 palillos [id] .acquire 0 

21 print "%d - Tengo ambos palillos" % id 

22 

23 def suelta_palillos (id) : 

24 palillos [ (id+1) % num] . release () 

25 palillos [id] . release 0 

26 print "%d - Sigamos pensando..." % id 

27 

28 def come (id) : 

29 print "%d - jA comer!" % id 

30 #(...) 



Podria pasar que todos los filosofos quieran comer al mismo tiempo y el 
planificador dejara suspendidos a todos con el palillo derecho en la mano. 
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Solucion 

Ahora, ^que pasa si se hace que algunos filosofos sean zurdos? Esto es, que 
levanten primero el palillo izquierdo y luego el derecho: 

1 def levanta_palillos (id) : 



2 if (id % 2 == 0) : # Zurdo 

3 palillol = palillos[id] 

4 palillo2 = palillos [ (id+1) % num] 

5 else: # Diestro 

6 palillol = paltos [ (id+1) % num] 

7 palillo2 = palillos [id] 

8 palillol . acquire 0 

9 print "%d - Tengo el primer palillo" % id 

10 palillo2 . acquire 0 

11 print "%d - Tengo ambos palillos" % id 



Al asegurar que dos filosofos contiguos no intenten levantar el mismo pa- 
lillo, se tiene la certeza de que no se produciran bloqueos mutuos. De hecho, 
incluso si solo uno de los filosofos es zurdo, se puede demostrar que no habra 
bloqueos: 

1 def levanta_palillos (id) : 



2 if id == 0: # Zurdo 

3 palillos [id] .acquire 0 

4 print "%d - Tengo el palillo izquierdo" % id 

5 palillos [ (id+1) % num] . acquire () 

6 else: # Diestro 

7 palillos [ (id+1) % num] . acquire () 

8 print "%d - Tengo el palillo derecho" % id 

9 palillos [id] .acquire 0 

10 print "%d - Tengo ambos palillos" % id 



Cabe apuntar que ninguno de estos mecanismos asegura que en la mesa no 
haya inanicion, solo que no haya bloqueos mutuos. 

3.3.8. Los fumadores compulsivos 
Planteamiento 

Hay tres fumadores empedemidos y un agente que, de tiempo en tiempo, 
consigue ciertos insimios. Los ingredientes necesarios para fumar son tabaco, 
papel y cerillos. Cada uno de los fumadores tiene una cantidad infinita de al- 
guno de los ingredientes, pero no les gusta compartir. Afortunadamente, del 
mismo modo que no comparten, no son acaparadores.^ 



^Esto es, no buscan obtener y conservar los recursos preventivamente, sino que los toman solo 
cuando satisfacen por completo sus necesidades. 
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De tiempo en tiempo, el agente consigue una dosis de dos de los ingredien- 
tes — por ejemplo, si deja en la mesa un papel y tabaco, el que trae los cerillos 
educadamente tomara los ingredientes, se hara un cigarro, y lo fumara. 

Suhas Patil (1971) planteo este problema buscando demostrar que hay si- 
tuaciones que no se pueden resolver con el uso de semaforos. Las condiciones 
planteadas son 

■ No se puede modificar el codigo del agente. Si el agente es un sistema 
operativo, jtiene sentido la restriccion de no tenerle que notificar acerca 
de los flujos a cada uno de los programas que ejecuta! 

■ El planteamiento original de Patil menciona que no deben emplearse 
arreglos de semaforos o usar condicionales en el flujo. Esta segunda res- 
triccion harla efectivamente irresoluble al problema, por lo que se igno- 
rara. 

Primer acercamiento 

Al haber tres distintos ingredientes, tiene sentido que se empleen tres dis- 
trntos semaforos, para senalizar a los fumadores respecto a cada uno de los 
ingredientes. Un primer acercamiento podrla ser: 

1 import random 

2 import threading 

3 ingredientes = ['tabaco', 'papel', 'cerillo'] 

4 semaforos = { } 

5 semaforo_agente = threading. Semaphore (1) 

6 for i in ingredientes : 



7 semaforos [i] = threading. Semaphore (0) 

s 

9 threading. Thread (target=agente, args= []). start () 

10 fiunadores = [threading. Thread (target=fumador, 
args= [i] ). start () for i in ingredientes] 

11 

12 def agente 0 : 

13 while True: 

14 semaforo_agente . acquire () 

15 mis_ingr = ingredientes [: ] 

1 6 mis_ingr . remove (random. choice (mis_ingr) ) 

1 7 for i in mis_ingr : 

18 print "Proveyendo %s" % i 

19 semaforos [i] .release 0 
20 

21 def fumador (ingr) : 

22 mis_semaf = [] 

23 for i in semaforos . keys () : 

24 if i != ingr: 
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25 mis_semaf . append (semaforos [i] ) 

26 while True: 

27 for i in mis_semaf : 

28 i. acquire 0 

29 fuina(ingr) 

30 semaf oro_agente . release ( ) 
31 

32 def fuma(ingr) : 

33 print ' Fumador con %s echando humo. . .' % ingr 



El problema en este caso es que, al tener que cubrir un niimero de ingredien- 
tes mayor a uno, utilizar solo un semaf oro ya no funciona: si agente ( ) decide 
proveer papel y cerillos, nada garantiza que no sea el fumador [ ' cerillo' ] 
el que reciba la primer serial o que fumador [ ' tabaco' ] reciba la segunda; 
para que este programa avance hace falta, mas que otra cosa, la buena suerte 
de que las senales sean recibidas por el proceso indicado. 

Solucion 

Una manera de evitar esta situacion es la utilizacion de intermediarios en- 
cargados de notificar al hilo adecuado. Partiendo de que, respetando la primer 
restriccion impuesta por Patil, no se puede modificar el codigo del agente, se 
implementan los intermediarios, se reimplementan los fumadores y se agregan 
algunas variables globales, de esta manera: 

1 que_tengo = { } 

2 semaf oros_interm = { } 

3 for i in ingredientes : 

4 que_tengo[i] = False 

5 semaforos_interm[i] = threading. Semaphore (0) 

6 

7 interm_mutex = threading. Semaphore (1) 

8 intermediaries = [threading . Thread (target=intermediario, 

args= [i] ). start () for i in ingredientes] 

9 

10 def fumador (ingr) : 



11 while True: 

12 semaforos_interm[ingr] . acquire () 

13 fuma (ingr) 

14 semaf oro_agente . release () 

15 

16 def intermediario (ingr) : 

1 7 otros_ingr = ingredientes [ : ] 

18 otros_ingr . remove (ingr) 

19 while True: 

20 semaforos [ingr] . acquire 0 

21 interm_mutex. acquire 0 
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22 for i in otros_ingr : 

23 if que_tengo [i] : 

24 que_tengo[i] = False 

25 semaforos_intenn[i] . release () 

26 break 

2 7 que_tengo[i] = True 

28 interm_mutex . release ( ) 



Si bien se ve que el codigo de f umador ( ) se simplifica (dado que ya no tie- 
ne que efectuar ninguna verificacion), intermediario ( ) tiene mayor com- 
plejidad. El elemento clave de su logica es que, si bien el agente ( ) (el sistema 
operativo) seguira enviando una senal por cada ingrediente disponible, los tres 
intermediarios se sincronizaran empleando al arreglo que_tengo (protegido 
por interm_mutex), y de este modo cada hilo (rndependientemente del orden 
en que fue invocado) senalizara a los otros intermediarios que ingredientes hay 
en la mesa, y una vez que sepa a que fumador notificar, dejara el estado listo 
para recibir una nueva notificacion. 

3.3.9. Otros mecanismos 

Mas alia de los mecanismos basados en mutexes y semaforos, hay otros que 
emplean diferentes niveles de encapsulamiento para proteger las abstracciones. 
A continuacion se presentan muy brevemente algunos de ellos. 

Monitores 

El principal problema con los mecanismos anteriormente descritos es que 
no solo hace falta encontrar un mecanismo que permita evitar el acceso simul- 
taneo a la seccion crltica sin caer en bloqueos mutuos o inanicion, sino que 
hay que implementarlo correctamente, empleando una semantica que requiere de 
bastante entrenamiento para entender correctamente. 

Ademas, al hablar de procesos que compiten por recursos de una forma hos- 
til, la implementacion basada en semaforos puede resultar insuficiente. A mode 
de ejemplo, se mostrara por que en el modelo original de Dijkstra (asl como en 
los ejemplos presentados anteriormente) solo se contemplan las operaciones de 
incrementar y decrementar, y no se permite verificar el estado (como lo ofrece 
sem_trywait ( ) enpthreads): 

1 while (sem_trywait (semaf oro) != 0) {} 

2 seccion_critica () ; 

3 sem__post (semaf oro) ; 



El codigo presentado es absolutamente valido — pero cae en una espera 
activa que desperdicia innecesaria y constantemente tiempo de procesador (y 
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no tiene garantia de tener mas exito que una espera pasiva, como seria el caso 
con un sem_wait ( ) ). 

For otro lado, algiin programador puede creer que su codigo ejecutara su- 
ficientemente rapido y con tan baja frecuencia que la probabilidad de que usar 
la seccion critica le cause problemas sea muy baja. Es frecuente ver ejemplos 
como el siguiente: 



1 /* Cruzamos los dedos . . 


a fin de cuentas, ejecutaremos con 


baja frecuencia! */ 




2 seccion_critica ( ) ; 





Los perjuicios causados por este programador resultan obvios. Sin embar- 
go, es comiin ver casos como este. 

Los monitores son estructuras provistas por el lenguaje o entorno de desa- 
rrollo que encapsulan tanto los datos como las funciones que los pueden manipu- 
lar, impidiendo el acceso directo a las funciones potencialmente peligrosas. En 
otras palabras, son tipos de datos abstractos {Abstract Data Types, ADT), clases de 
objetos, y exponen una serie de metodos publicos, ademas de poseer metodos priva- 
dos que emplean intemamente. 

Al no presentar al usuario / programador una interfaz que puedan subvertir, 
el monitor mantiene todo el codigo necesario para asegurar el acceso concu- 
rrente a los datos en un solo lugar. 

Un monitor puede implementarse utilizando cualquiera de los mecanismos 
de sincronizacion presentados anteriormente — la diferencia radica en que esto 
se hace en un solo lugar. Los programas que quieran emplear el recurso protegi- 
do lo hacen incluyendo el codigo del monitor como modulo /biblioteca, lo cual 
fomenta la reutilizacion de codigo. 

Como ejemplo, el lenguaje de programacion Java implementa sincroniza- 
cion via monitores entre hilos como una propiedad de la declaracion de meto- 
do, y lo hace directamente en la JVM. Si se declara un metodo de la siguiente 
manera: 

1 public class SimpleClass { 

2 // . . . 

3 public synchronized void metodoSeguro () { 

4 /* Implementacidn de metodoSeguro ( ) */ 

5 // . . . 

6 } 

7 } 



Y se inicializa a un SimpleClass sc = new SimpleClass (), cuan- 
do se llame a sc .metodoSeguro ( ) , la maquina virtual verificara si ningiin 
otro proceso esta ejecutando metodoseguro { ) ; en caso de que no sea asl, 
le permitira la ejecucion obteniendo el candado, y en caso de si haberlo, el 
hilo se bloqueara hasta que el candado sea liberado, esto es, la propiedad 
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synchroni zed hace que todo acceso al metodo en cuestion sea protegido por 
una mutex. 

El modelo de sincronizacion basado en monitores no solo provee la exclu- 
sion mutua. Mediante variables de condicion se puede tambien emplear una se- 
mantica parecida (aunque no igual) a la de los semaforos, con los metodos 
var . wait ( ) y var . signal ( ) . En el caso de los monitores, var . wait ( ) 
suspende al hilo hasta que otro hilo ejecute var . signal (); en caso de no 
haber ningun proceso esperando, var. signal () no tiene ningun efecto (no 
cambia el estado de var, a diferencia de lo que ocurre con los semaforos). 

Aqui se presenta, a modo de ilustracion, la resolucion del problema de la 
cena de losfilosofos en C.^ Esto demuestra, ademas, que si bien se utiliza seman- 
tica de orientacion a objetos, no solo los lenguajes clasicamente relacionados 
con la programacion orientada a objetos permiten emplear monitores. 

1 /* Implementacion para cinco fllosofos */ 

2 ttdefine PENSANDO 1 

3 #define HAMBRIENTO 2 

4 #define COMIENDO 3 

5 

6 pthread_cond_t VC[5]; /* Una VC por filosofo */ 

7 pthread_mutex_t M; /* Mutex para el monitor */ 

8 int estado[5]; /* Estado de cada filosofo */ 
9 

10 void palillos_init () { 

1 1 int i ; 

12 pthread_mutex_init (&M, NULL) ; 

13 for (i = 0; i < 5; i++) { 

14 pthread_cond_init(&VC[i] , NULL) ; 

15 estado [i] = PENSANDO; 



16 



} 



17 } 



18 



20 



21 



23 



22 



19 voii 



d toma_palillos (int i) { 
pthread_mutex_lock ( &M) 
estado [i] = HAMBRIENTO; 
actualiza (i) ; 

while (estado [i] == HAMBRIENTO) 



25 



24 



pthread_cond_wait (SVC [i] , &M) ; 
pthread_mutex_unlock (&M) ; 



26 } 



27 



28 void suelta_palillos (int i) { 

29 estado [i] = PENSANDO; 

30 actualiza ((i - 1) % 5) ; 



'implementacion basada en el ejemplo de Ted Baker, sobre la solucion propuesta por Tanen- 
baum. 
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31 actualiza((i + 1) % 5) ; 

32 pthreaci_mutex_unlock ( &M) ; 

33 } 

34 

35 void come(int i) { 

36 printf("El filosofo %d esta comiendo\n" , i) ; 

37 } 

38 

39 void piensa(int i) { 

40 printf("El filosofo %d esta pensando\n", i) ; 

41 } 

42 

43 /* No incluir 'actualiza' en los encabezados , */ 

44 / * es una funcion interna/privada */ 

45 int actualiza (int i) { 

46 if ((estado[(i - 1) % 5] != COMIENDO) && 

47 (estado[i] == HAMBRIENTO) && 

48 (estado[(i +1) % 5] != COMIENDO)) { 

49 estado[i] = COMIENDO; 

50 pthread_cond_signal (&VC [i] ) ; 

51 } 

52 return 0; 

53 } 



Esta implementacion evita los bloqueos mutuos senalizando el estado de 
cada uno de los filosofos en el arreglo de variables estado [] . 

La logica base de esta resolucion marca en la verificacion del estado pro- 
pio y de los vecinos siempre que hay un cambio de estado: cuando el filo- 
sofo i llama a la funcion toma_palillos (i), esta se limita a adquirir el 
mutex M, marcar su estado como HAMBRIENTO, y llamar a la funcion interna 
actualiza (i) . Del mismo modo, cuando el filosofo i termina de comer y lla- 
ma a suelta_palillos (i) , esta funcion marca su estado como PENSANDO 
e invoca a actualiza ( ) dos veces: una para el vecino de la izquierda y otra 
para el de la derecha. 

Es importante recalcar que, dado que esta solucion esta estructurada como 
im monitor, ni actualiza () ni las variables que determinan el estado del 
sistema (vc, M, estado) son expuestas a los hilos uivocantes. 

La funcion actualiza (i) es la que se encarga de verificar (y modificar, 
de ser el caso) el estado no solo del filosofo invocante, sino que de sus veci- 
nos. La logica de actualiza ( ) permite resolver este problema abstrayendo 
(y eliminando) a los molestos palillos: en vez de preocuparse por cada palillo 
individual, actualiza ( ) impide que dos filosofos vecinos esten COMIENDO 
al mismo tiempo, y dado que es uivocada tanto cuando un filosofo toma_- 
palillos ( ) como cuando suelta_palillos ( ) , otorga el turno al vecino 
sin que este tenga que adquirir expHcitamente el control. 
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Estas caracteristicas permite que la logica central de cada uno de los filoso- 
fos se simplifique a solo: 

1 void *f ilosof o (void *arg) { 

2 int self = * (int *) arg; 

3 for (;;) { 

4 piensa (self) ; 

5 toma_palillos (self) ; 

6 come (self) ; 

7 suelta_palillos (self ) ; 

8 } 

9 } 
10 

1 1 int main ( ) { 

12 int i; 

13 pthread_t th[5]; /* IDs de los hilos filosofos */ 

14 pthread_attr_t attr = NULL; 

15 palillos_init 0 ; 

16 for (i=0; i<5; i++) 

17 pthread_create (&th [i] , attr, filosofo, (int*) &i) ; 

18 for (i=0; i<5; i++) 

19 pthread_join(th[i] ,NULL) ; 



Al ser una solucion basada en monitor, el codigo que invoca afilosofo(i) 
no tiene que estar al pendiente del mecanismo de sincronizacion empleado, 
puede ser comprendido mas facilmente por un lector casual y no brinda opor- 
tunidad para que un mal programador haga mal uso del mecanismo de sincro- 
nizacion. 

Memoria transaccional 

Un area activa de investigacion hoy en dla es la de la memoria transaccional. 
La logica es ofrecer primitivas que protejan a un conjunto de accesos a memoria 
del mismo modo que ocurre con las bases de datos, en las que tras abrir una 
transaccion, se puede realizar una gran cantidad (no ilimitada) de tareas, y al 
terminar con la tarea, confirmarlas (commit) o rechazarlas (rollback) atomicamente 
— y, claro, el sistema operativo indicara exito o fracaso de forma atomica al 
conjunto entero. 

Esto facilitarfa mucho mas aun la sincronizacion: en vez de hablar de seccio- 
nes crtticas, se podrla reintentar la transaccion y solo preocuparse de revisar si 
fue exitosa o no, por ejemplo: 



20 } 



1 do { 



2 



3 



4 



begin_transaction 0 ; 
varl = var2 * var3; 
var3 = var2 - varl ; 
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5 var2 = varl / var2; 

6 } while (! coinmit_transaction () ) ; 



Si en el transcurso de la transaccion algiin otro proceso modifica alguna de 
las variables, esta se abortara, pero se puede volver a ejecutar. 

Claro esta, el ejemplo presentado desperdicia recursos de proceso (lleva a 
cabo los calculos al tiempo que va modificando las variables), por lo cual serla 
un mal ejemplo de seccion crltica. 

Hay numerosas implementaciones en software de este principio {Software 
Transactional Memory, STM) para los prrncipales lenguajes, aunque el plantea- 
miento ideal sigue apuntando a una implementacion en hardware. Hay casos 
en que, sin embargo, esta tecnica puede aiin llevar a resultados rnconsistentes 
(particularmente si un proceso lector puede recibir los valores que van cam- 
biando en el tiempo por parte de un segundo proceso), y el costo computacio- 
nal de dichas operaciones es elevado, sin embargo, es una construccion muy 
poderosa. 

3.4. Bloqueos mutuos 

Un bloqueo mutuo puede ejemplificarse con la situacion que se presenta 
cuando cuatro automovilistas llegan al mismo tiempo al cruce de dos avenidas 
del mismo rango en que no hay un semaforo, cada uno desde otra direccion. 
Los reglamentos de transito sefialan que la precedencia la tiene el automovilista 
que viene mas por la derecha. En este caso, cada uno de los cuatro debe ceder el 
paso al que tiene a la derecha — y ante la ausencia de un criterio humano que 
rompa el bloqueo, deberlan todos mantenerse esperando por siempre. 

Un bloqueo mutuo se presenta cuando {Condiciones de Coffman) (La Red, p. 
185): 

1. Los procesos reclaman control exclusivo de los recursos que piden (con- 
dicion de exclusion mutua). 

2. Los procesos mantienen los recursos que ya les han sido asignados mien- 
tras esperan por recursos adicionales (condicion de espera por). 

3. Los recursos no pueden ser extraldos de los procesos que los tienen hasta 
su completa utilizacion (condicion de no apropiatividad) . 

4. Hay una cadena circular de procesos en la que cada uno mantiene a uno 
o mas recursos que son requeridos por el siguiente proceso de la cadena 
(condicion de espera circular). 

Las primeras tres condiciones son necesarias pero no suficientes para que se 
produzca un bloqueo; su presencia puede rndicar una situacion de riesgo. Solo 
cuando se presentan las cuatro se puede hablar de un bloqueo mutuo efectivo. 
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Otro ejemplo clasico es un sistema con dos unidades de cinta (dispositivos 
de acceso secuencial y no compartible), en que los procesos AyB requieren de 
ambas unidades. Dada la siguiente secuencia: 

1. A solicita una unidad de cinta y se bloquea. 

2. B solicita una unidad de cinta y se bloquea. 

3. El sistema operativo otorga la unidad 1 a A, y le vuelve a otorgar la eje- 
cucion. B permanece bloqueado. 

4. A continua procesando; termina su periodo de ejecucion. 

5. El sistema operativo otorga la unidad 2 al proceso B, y lo vuelve a poner 
en ejecucion. 

6. B solicita otra unidad de cinta y se bloquea. 

7. El sistema operativo no tiene otra unidad de cinta por asignar. Mantiene 
a B bloqueado; otorga el control de vuelta a A. 

8. A solicita otra unidad de cinta y se bloquea. 

9. El sistema operativo no tiene otra unidad de cinta por asignar. Mantiene 
bloqueado tanto A como B y otorga el control de vuelta a otro proceso (o 
queda en espera). En este caso ni A ni B seran desbloqueados nimca. 




Figura 3.6: Esquema clasico de un bloqueo mutuo simple: los procesos AyB espe- 
ran mutuamente para el acceso a las unidades de cinta 1 y 2. 

Sin una politica de prevencion o resolucion de bloqueos mutuos, no hay 
modo de que Ao B contimien su ejecucion. Se veran algimas estrategias para 
enfrentar los bloqueos mutuos. 
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En el apartado de Exclusion mutua, los hilos presentados estaban disenados 
para cooperar expltcitamente. Un sistema operativo debe ir mas alia, tiene que 
implementar poltticas que eviten, en la medida de lo posible, dichos bloqueos 
incluso entre procesos completamente independientes. 

Las poHticas tendientes a otorgar los recursos lo antes posible cuando son 
solicitadas pueden ser vistas como liberales, en tanto que las que controlan mas 
la asignacion de recursos, conservador as. 



Bloqueo posible 
Siempre otorgar (Avestruz) 



Deteccion y recuperacion 



Evasion de bioqueos 
(Con conocimiento previo) 



Fiujos seguros e inseguros 



Aigoritmo dei banquero 




Mas caro (complejo) 
para el sistema operativo 



Iwlas barato (senciiio) 
para procesos usuario 



Mas caro (compiejo) 

para procesos usuario 



Iwlas barato (senciiio) 
para el sistema operativo 



Conservador 



Figura 3.7: Espectro liberal-conservador de esquemas para evitar bloqueos. 

Las lineas principales que describen las estrategias para enfrentar situacio- 
nes de bloqueo (La Red, p. 188) son: 

Prevencion Se centra en modelar el comportamiento del sistema para que eli- 
mine toda posibilidad de que se produzca \m bloqueo. Resiilta en una utili- 
zacion suboptima de recursos. 

Evasion Busca imponer condiciones menos estrictas que en la prevencion, pa- 
ra intentar lograr una mejor utilizacion de los recursos. Si bien no puede 
evitar todas las posibilidades de im bloqueo, cuando este se produce busca 
evitar sus consecuencias. 

Deteccion y recuperacion El sistema permite que ocuxran los bloqueos, pero 
busca determinar si ha ocurrido y tomar medidas para eliminarlo. 
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Busca despejar los bloqueos presentados para que el sistema continue 
operando sin ellos. 

3.4.1. Prevencion de bloqueos 

Se presentan a continuacion alguxios algoritmos que implementan la pre- 
vencion de bloqueos. 

Serializacion 

Una manera de evitar bloqueos por completo seria el que un sistema operati- 
vo jamas asignara recursos a mas de vn proceso a la vez — los procesos podrian 
seguir efectuando calculos o empleando recursos no rivales (que no requieran 
acceso exclusive — por ejemplo, empleo de archivos en el disco, sin que exista 
un acceso directo del proceso al disco), pero solo uno podrla obtener recursos 
de forma exclusiva al mismo tiempo. Este mecanismo seria la serializacion, y la 
situacion antes descrita se resolveria de la siguiente manera: 

1. A solicita ima imidad de cinta y se bloquea. 

2. B solicita una uxiidad de cinta y se bloquea. 

3. El sistema operative otorga la unidad 1 a A y lo vuelve a poner en ejecu- 
cion. B permanece bloqueado. 

4. A contimia procesando; termina su periodo de ejecucion. 

5. El sistema operative mantiene bloqueado a B, dado que A tiene un recur- 
so asignado. 

6. A solicita otra unidad de cinta y se bloquea. 

7. El sistema operative otorga la unidad 2 a A y lo vuelve a poner en ejecu- 
cion. B permanece bloqueado. 

8. A libera la unidad de cinta 1. 

9. A libera la unidad de cinta 2 (y con ello, el bloqueo de uso de recursos). 

10. El sistema operative otorga la unidad 1 a B y le otorga la ejecucion. 

11. B solicita otra unidad de cinta y se bloquea. 

12. El sistema operative otorga la unidad 2 a B y lo pone nuevamente en 
ejecucion. 

13. B libera la unidad de cinta 2 . 

14. B libera la unidad de cinta 2. 
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Si bien la serializacion resuelve la situacion aqui mencionada, el mecanismo 
empleado es suboptimo dado que puede haber hasta n-1 procesos esperando a 
que uno libere los recursos. 

Un sistema que implementa una politica de asignacion de recursos basada 
en la serializacion, si bien no caera en bloqueos mutuos, si tiene un peligro 
fuerte de caer en inanicion. 

Retencion y espera (advance claim) 

Otro ejemplo de politica preventiva menos conservadora seria la retencion y 
espera o reserva {advance claim): que todos los programas declaren al iniciar su 
ejecucion que recursos van a requerir. Estos son apartados para su uso exclusi- 
vo hasta que el proceso termina, pero el sistema operativo puede seguir aten- 
diendo solicitudes que no rivalicen: si a los procesos Ay B anteriores se suman 
procesos C y D, pero requieren otro tipo de recursos, podrian ejecutarse en pa- 
ralelo A, C y D, y una vez que A termine, podrian continuar ejecutando B, C y 
D. 

El bloqueo resulta ahora imposible por diseno, pero el usuario que inicio B 
tiene una percepcion de injusticia dado el tiempo que tuvo que esperar para 
que su solicitud fuera atendida — de hecho, si A es un proceso de larga du- 
racion (incluso si requiere la unidad de cinta solo por un breve periodo), esto 
lleva a que B sufra una inanicion innecesariamente prolongada. 

Ademas, la implementacion de este mecanismo preventive requiere que el 
programador sepa por anticipado que recursos requerira — y esto en la reali- 
dad muchas veces es imposible. Si bien podria disenarse una estrategia de lan- 
zar procesos representantes (o proxy) solicitando recursos especificos cuando es- 
tos hicieran falta, esto solo transferiria la situacion de bloqueo por recursos a 
bloqueo por procesos — y un programador poco cuidadoso podria de todos 
modos desencadenar la misma situacion. 

Solicitud de una vez {one-shot) 

Otro mecanismo de prevencion de bloqueos seria que los recursos se otor- 
guen exclusivamente a aquellos procesos que no poseen ningun recurso. Esta es- 
trategia romperia la condicion de Coffman espera por, haciendo imposible que 
se presente vn bloqueo. 

En su planteamiento inicial, este mecanismo requeria que un proceso de- 
clarara una sola vez que recursos requeriria, pero posteriormente la estrategia 
se modifico, permitiendo que un proceso solicite recursos nuevamente, pero 
unicamente con la condicion de que previo a hacerlo renuncien a los recursos 
que teman en ese momento; claro, pueden volver a incluirlos en la operacion 
de solicitud. 

Al haber una renuncia expUcita, se imposibilita de forma tajante que un con- 
junto de procesos entre en condicion de bloqueo mutuo. 
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Las principales desventajas de este mecanismo son: 

■ Requiere cambiar la logica de programacion para tener pimtos mas defi- 
nidos de adquisicion y liberacion de reciirsos. 

■ Muchas veces no basta con la readquisicion de un recurso, sino que es 
necesario mantenerlo bloqueado. Volviendo al ejemplo de las unidades de 
cinta, un proceso que requiera ir generando un archivo largo no puede 
arriesgarse a soltarla, pues podria ser entregada a otro proceso y corrom- 
perse el resiiltado. 

Asignacion jerarquica 

Otro mecanismo de evasion es la cLsignncion jerarquica de recursos. Bajo es- 
te mecanismo, se asigna una prioridad o nivel jerdrquico a cada recurso o clase 
de recursos.^'' La condicion basica es que, una vez que un proceso obtiene un 
recurso de determinado nivel, solo puede solicitar recursos adicionales de ni- 
veles superiores. En caso de requerir dos dispositivos ubicados al mismo nivel, 
tiene que hacerse de forma atomica. 

De este modo, si las unidades de cinta tienen asignada la prioridad x, Pi 
solo puede solicitar dos de ellas por medio de una sola operacion. En caso de 
tambien requerir dos imidades de cinta el proceso P2 al mismo tiempo, al ser 
atomicas las solicitudes, estas le seran otorgadas a solo uxio de los dos procesos, 
por lo cual no se presentara bloqueo. 

Ademas, el crear una jerarquia de recursos permitiria ubicar los recursos 
mas escasos o peleados en la cima de la jerarquia, reduciendo las situaciones 
de contendon en que varios procesos compiten por dichos recursos — solo lle- 
garian a solicitarlos aquellos procesos que ya tienen asegurado el acceso a los 
demas recursos que vayan a emplear. 

Sin embargo, este ordenamiento es demasiado estricto para muchas situa- 
ciones del mundo real. El tener que renunciar a ciertos recursos para adquirir 
vno de menor prioridad y volver a competir por ellos, ademas de resultar contra- 
intuitivo para un programador, resulta en esperas frustrantes. Este mecanismo 
Uevaria a los procesos a acaparar recursos de baja prioridad, para evitar te- 
ner que ceder y re-adquirir recursos mas altos, por lo que conduce a una alta 
inanicion. 

3.4.2. Evasion de bloqueos 

Para la evasion de bloqueos, el sistema partirfa de poseer, ademas de la 
informacion descrita en el caso anterior, conocer cudndo requiere un proceso 

^"incluso varios recursos distintos, o varias clases, pueden compartir prioridad, aunque esto di- 
ficultaria la programacibn. Podria verse la solicitud de una vez como im caso extreme de asignaci6n 
jerarquica, en la que todos los recursos tienen el mismo nivel. 
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utilizar cada recurso. De este modo, el planificador puede marcar que orden 
de ejecucion (esto es, que flujos) entre dos o mas procesos son seguros y cuales 
son inseguros 
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Figura 3.8: Evasion de bloqueos: los procesos A (horizontal) y B (vertical) requieren 
del acceso exclusive a un plotter y una impresora, exponiendose a bloqueo mutuo. 

El analisis de la interaccion entre dos procesos se representa como en la 
figura 3.8; el avance es marcado en sentido horizontal para el proceso A, o 
vertical para el proceso B; en un sistema multiprocesador, podria haber avance 
mutuo, y se indicaria en diagonal. 

En el ejemplo presentado, el proceso A solicita acceso exclusivo al scanner 
durante 2 < t/^ < 7 y a la impresora durante 3 < f/i < 7,5, mientras que 
B solicita acceso exclusivo a la impresora durante 2 < < 6 y al scanner 
durante 4 < ig < 7. 

Al saber cuando reclama y libera un recurso cada proceso, se puede marcar 
cual es el area segura para la ejecucion y cuando se esta aproximando a un area 
de riesgo. 

En el caso mostrado, si bien el bloqueo mutuo solo se produciria formal- 
mente en cualquier punto^^ en 3 < f/i < 7, y 4 < tg < 6 (indicado con el 
recuadro Bloqueo mutuo). 

Pero la existencia del recuadro que indica el bloqueo mutuo podria ser re- 
velada con anterioridad: si el flujo entra en el area marcada como bloqueo in- 
minente (en 3 < < 7 y 2 < fg < 6), resulta ineludible caer en el bloqueo 
mutuo. 

La region de bloqueo inminente ocurre a partir de que A obtuvo el scanner 
y B obtuvo la impresora. Si en = 2,5 y fg =3 se cede la ejecucion a A por 0.5 

^^En realidad, solo seria posible tocar el margen izquierdo o inferior de este bloque: al caer en 
bloqueo mutuo, avanzar hacia su area interior resultaria imposible. 
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unidades, se llegara al punto en que solicita la impresora {t^ — 3), y no habra 
mas remedio que ejecutar B; al avanzar B 0.5 unidades requerira al scanner, y 
se habra desencadenado el bloqueo mutuo. Un caso analogo ocurre, claro esta, 
si desde el punto de inicio se ejecutara primero B y luego A. 

Dadas las anteriores condiciones, y conociendo estos patrones de uso, el 
sistema operative evitara entrar en el area de bloqueo inminente: el sistema 
mantendra en espera a B si < 2 mientiras 2 < < 6, y mantendra a A en 
espera si f/i < 2 cuando 2 < tg < 6. 

La region marcada como inalcanzable no representa ningun peligro: solo in- 
dica aquellos estados en que resulta imposible enti-ar. Incluso una vez evadido 
el bloqueo (por ejemplo, si B fue suspendido en tg = 1,8 y A avanza hasta 
pasar tA = 7, si el sistema operative vuelve a dar la ejecucion a B, este solo 
podra avanzar hasta ts — 2, punto en que B solicita la impresora. Para que B 
continue, es necesario llegar hasta > 7,5 para que B siga avanzando. 

Este mecanismo proveeria una mejor respuesta que los vistos en el apartado 
de prevencion de bloqueos, pero es todavia mas dificil de aplicar en situaciones 
reales. Para poder implementar un sistema con evasion de bloqueos, tendria 
que ser posible hacer un analisis estatico previo del codigo a ejecutar, y tener 
un listado total de recursos estatico. Estos mecanismos podrian ser efectivos en 
sistemas de uso especializado, pero no en sistemas operatives (e planificade- 
res) generices. 

Algoritmo del banquero 

Edsger Dijkstra propuso un algoritmo de asignacion de recursos orientado 
a la evasion de bloqueos a ser empleado para el sistema operative THE (desa- 
rrollado entre 1965 y 1968 en la Escuela Superior Tecnica de Eindhoven, Tech- 
nische Hogeschool Eindhoven), un sistema multiprogramado organizado en 
anillos de privilegios. El nombre de este algoritmo proviene de que busca que 
el sistema opere cuidando de tener siempre la liquidez (nunca entrar a estados 
inseguros) para satisfacer los prestamos (recursos) solicitados por sus clientes 
(quienes a su vez tienen una Imea de credito pre-autorizada por el banco). 

Este algoritmo permite que el conjunto de recursos solicitado por los pro- 
cesos en ejecucion en el sistema sea mayor a los fisicamente disponibles, pero 
mediante un monitoreo y control en su asignacion, logra este nivel de sobre- 
compromiso sin poner en riesgo la operacion correcta del sistema. 

Este algoritmo debe ejecutarse cada vez que un proceso solicita recursos; 
el sistema evita caer en situaciones conducentes a un bloqueo mutuo ya sea 
denegando o posponiendo la solicitud. El requisite particular es que, al iniciar, 
cada proceso debe anunciar su reclamo maxima (llamese claim ( ) ) al sistema: 
el niimero maximo de recursos de cada tipe que va a emplear a lo largo de 
su ejecucion; este seria implementade come una Uamada al sistema. Una vez 
que un proceso presento su reclamo maximo de recujsos, cualquier Uamada 
subsecuente a claim ( ) faUa. Clare esta, si el proceso animcia una necesidad 
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mayor al numero de recursos de algun tipo que hay, tambien falla dado que el 
sistema no sera capaz de cumplirlo. 

Para el algoritmo del banquero, a partir del punto evaluado se analizaran 
las transiciones a traves de estados: matrices de recursos disponibles, reclamos 
maximos y asignacion de recursos a los procesos en un momenta dado. Estos 
pueden ser: 

■ Un estado seguro, si tados los procesos pueden continuar desde el mo- 
menta evaluado hasta el final de su ejecucion sin encontrar im bloqueo 
mutuo. 

■ Un estado inseguro es tado aquel que no garantice que tados los procesos 
puedan continuar hasta el final sin encontrar un bloqueo mutuo. 

Este algoritmo tlpicamente trabaja basado en diferentes categorias de recur- 
sos, y los reclamos maximos anunciados por los procesos son por cada una de 
las categorias. 

El estado esta compuesto, por clase de recursos y por proceso, por: 
Reclamado numero de instancias de este recurso que han sido reclamadas. 

Asignado numero de instancias de este reciurso actualmente asignadas a pro- 
cesos en ejecucion. 

Solicitado numero de instancias de este recurso actualmente pendientes de 
asignar (solicitudes hechas y no cumplidas). 

Ademas de esto, el sistema mantiene globahnente, por clase de recursos: 

Disponibles numero total de instancias de este recurso disponibles al sistema. 

Libres numero de instancias de este recurso que no estan actualmente asigna- 
das a ningiin proceso. 

Cada vez que un proceso solicita recursos, se calcula cual seria el estado 
resiiltante de otorgar dicha solicitud, y se otorga siempre que: 

■ No haya reclamo por mas recursos que los disponibles. 

■ Ningiin proceso solicite (o tenga asignados) recursos por encima de su 
reclamo. 

■ La suma de los recursos asignados por cada categorla no sea mayor a la 
cantidad de reciirsos disponibles en el sistema para dicha categoria. 

Formalmente, y volviendo a la definicion anterior: im estado es seguro cuan- 
do hay una secuencia de procesos (denominada secuencia seguro) tal que: 
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1. Un proceso ; puede necesariamente terminar su ejecucion, incluso si soli- 
citara todos los recursos que permite su reclamo, dado que hay suficien- 
tes recursos libres para satisfacerlo. 

2. Un segundo proceso k de la secuencia puede terminar si / termina y libera 
todos los recursos que tiene, porque sumado a los reciirsos disponibles 
ahora, con aqueUos que liberaria hay suficientes recursos libres para 
satisfacerlo. 

3. El f-esimo proceso puede terminar si todos los procesos anteriores termi- 
nan y liber an sus recursos. 

En el peor de los casos, esta secuencia segura llevarla a bloquear todas las 
solicitudes excepto las del unico proceso que puede avanzar sin peligro en el 
orden presentado. 

Se presenta un ejemplo simplificando, asiimiendo solo vma clase de proce- 
sos, e iniciando con dos instancias libres: 

Proceso Asignado Reclamando 

4 6~ 

B 4 11 

C 2 7 



A puede terminar porque solo requiere de 2 instancias adicionales para lle- 
gar a las 6 que indica en su reclamo. Una vez que termine, liberara sus 6 ins- 
tancias. Se le asignan entonces las 5 que solicita a C, para llegar a 7. Al terminar 
este, habra 8 disponibles, y asignandole 7 a B se garantiza poder terminar. La 
secuencia (A, C, B) es una secuencia segura. 

Sin embargo, el siguiente estado es inseguro (asiimiendo tambien dos ins- 
tancias libres): 

Proceso Asignado Reclamado 

4 6~ 
B 4 11 

C 2 9 



A puede terminar, pero no se puede asegurar que B o C puedan hacerlo, ya 
que incluso una vez terminando A, tendrian solo seis instancias no asignadas: 
menos que las siete que ambos podrian a requerir segun sus reclamos iniciales. 

Es necesario apuntar que no hay garantta de que continuar a partir de este 
estado lleve a un bloqueo mutuo, dado que B o C pueden no incrementar ya 
su utilizacion hasta cubrir su reclamo, esto es, puede que lleguen a finalizar 
sin requerir mas recursos, ya sea porque los emplearon y liberaron, o porque el 
uso efectivo de recursos requeridos senciUamente resulte menor al del reclamo 
inicial. 
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El algoritmo del banquero, en el peor caso, puede tomar 0(n!), aunque 
tipicamente ejecuta en O(m^). Una implementacion de este algoritmo podria 
ser: 

1 1 = ['A', 'B', ' C , 'D', 'E']; # Todos los procesos del sistema 

2 s = []; # Secuencia segura 

3 while ! 1 . empty? do 

4 p = 1 . select {lidl reclamado [id] - asignado[id] > 

libres} . first 

5 raise Exception, 'Estado inseguro' if p. nil? 

6 libres += asignado[p] 

7 1. delete (p) 

8 s.push(p) 

9 end 

10 puts "La secuencia segura encontrada es: %s" % s 

Hay refinamientos sobre este algoritmo que logran resultados similares, re- 
duciendo su costo de ejecucion (se debe recordar que es un procedimiento que 
puede ser llamado con muy alta frecuencia), como el desarrollado por Haber- 
mann (Finkel, p. 136). 

El algoritmo del banquero es conservador, dado que evita entrar en un es- 
tado inseguro a pesar de que dicho estado no lleve con certeza a un bloqueo 
mutuo. Sin embargo, su polltica es la mas liberal que permite asegurar que no 
se caera en bloqueos mutuos, sin conocer el orden y tiempo en que cada uno de 
los procesos requerirla los recursos. 

Una desventaja importante de todos los mecanismos de evasion de blo- 
queos es que requieren saber por anticipado los reclamos maximos de cada 
proceso, lo cual puede no ser conocido en el momento de su ejecucion. 

3.4.3. Deteccion y recuperacion de bloqueos 

La deteccion de bloqueos es una forma de reaccionar ante una situacion de 
bloqueo que ya se produjo y de buscar la mejor manera de salir de ella. Esta 
podria ejecutarse ser una tarea periodica, y si bien no puede prevenir situaciones 
de bloqueo, puede detectarlas una vez que ya ocurrieron y limitar su efecto. 

Manteniendo una lista de recursos asignados y solicitados, el sistema ope- 
rativo puede saber cuando un conjunto de procesos estan esperandose mu- 
tuamente en una solicitud por recursos — al analizar estas tablas como grafos 
dirigidos, se representara: 

■ Los procesos, con cuadrados. 

■ Los recursos, con circulos. 

• Puede representarse como un circulo grande a una clase o categoria 
de recursos, y como circulos pequenos dentro de este a una serie de 
recursos identicos (p. ej. las diversas unidades de cinta). 
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■ Las flechas que van de un recurso a un proceso indican que el recurso estd 
asignado al proceso. 

■ Las flechas que van de un proceso a un recurso indican que el proceso 
solicita el recurso. 

Cabe mencionar en este momento que, cuando se consideran categorias de 
recursos, el tener la representacion visual de un ciclo no implica que haya ocu- 
rrido un bloqueo; este solo se presenta cuando todos los procesos involucrados 
estan en espera mutua. 



P3 




Figura 3.9: Al emplear categorias de recursos, un ciclo no necesariamente indica un 
bloqueo. 

En la figura 3.9, si bien y P2 estan esperando que se liberen recursos de 
tipo Ri y P?i y Pi siguen operando normalmente, y se espera que lleguen 
a liberar el recurso por el cual estan esperando. En el caso ilustrado, dado que 
el bloqueo se presenta unicamente al ser imposible que un proceso lihere recur- 
sos que ya lefueron asignados, tendria que presentarse un caso donde todos los 
recursos de una misma categoria estuvieran involucrados en una situacion de 
espera circular, como la ilustrada a continuacion. 

Si se tiene una representacion completa de los procesos y recursos en el sis- 
tema, la estrategia es reducir la grafica retirando los elementos que no brinden 
informacion imprescindible, siguiendo la siguiente logica (recordar que repre- 
sentan una fotografia del sistema en un momento dado): 

■ Se retiran los procesos que no estan solicitando ni tienen asignado ningun 
recurso. 

■ Para todos los procesos restantes: si todos los recursos que estan solicitan- 
do pueden ser concedidos (esto es, no estan actualmente asignados a otro). 
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se reduce eliminando del grafo al proceso y a todas las flechas relaciona- 
das con este. 

■ Si despues de esta reduccion se eliminan todos los procesos del grafo, 
entonces no hay interbloqueos y se puede contmuar. En caso de perma- 
necer procesos en el grafo, los procesos "irreducibles" constituyen la serie 
de procesos interbloqueados de la grafica. 



E 




Figum 3.11: Deteccion de ciclos denotando bloqueos: grafo de procesos y recursos 
en un momento dado. 

Para resolver la situacion planteada en la figura 3.11 se puede proceder de 
la siguiente manera: 

■ Se reduce por B, dado que actualmente no esta esperando a ningiin re- 
curso. 
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■ Se reduce por AyF, dado que los recursos por los cuales estan esperando 
quedan libres en ausencia de B. 

■ Y queda mv interbloqueo entre C,DyE, en tomo a los recursos 4, 5 y 7. 

Notese que reducir un proceso del grafo no implica que este haya entregado 
sus recursos, sino unicamente que, hasta donde se tiene conocimiento, tiene 
posibilidad de hacerlo. Los procesos que estan esperando por recursos retenidos 
por un proceso pueden sufrir inanicion aun por un tiempo indeterminado. 

Una vez que unbloqueo es diagnosticado, dado que los procesos no podran 
terminar por si mismos (pues estan precisamente bloqueados, su ejecucion no 
avanzara mas), hay varias estrategias para la recuperacion: 

■ Terminar a todos los procesos bloqueados. Esta es la tecnica mas sencilla 
y, de cierto modo, mas justa — todos los procesos implicados en el blo- 
queo pueden ser relanzados, pero todo el estado del computo que han 
reaUzado hasta este momento se perdera. 

■ Retroceder a los procesos implicados hasta el ultimo punto de control (check- 
point) seguro conocido. Esto es posible unicamente cuando el sistema im- 
plementa esta funcionalidad, que tiene un elevado costo adicional. Cuan- 
do el estado de uno de los procesos depende de factores extemos a este, 
es imposible implementar fielmente los puntos de control. 

Podria parecer que retroceder a un punto previo Uevarla indefectible- 
mente a que se repita la situacion — pero los bloqueos mutuos requieren 
de un orden de ejecucion especifico para aparecer. Muy probablemen- 
te, una ejecucion posterior lograra salvar el bloqueo y, en caso contrario, 
puede repetirse este paso. 

■ Terminar, vno por vno y no en bloque, a cada tmo de los procesos blo- 
queados. Una vez que se termina uno, se evaliia la situacion para verificar 
si logro romperse la situacion de bloqueo, en cuyo caso la ejecucion de los 
restantes contimia sin interrupcion. 

Para esto, si bien podria elegirse un proceso al azar de entre los bloquea- 
dos, tipicamente se consideran elementos adicionales como: 

• Los procesos que demandan garantlas de tiempo real (ver seccion 4.5) 
son los mas sensibles para detener y relanzar. 

• La menor cantidad de tiempo de procesador consumido hasta el mo- 
mento. Dado que el proceso probablemente tenga que ser re-lanzado 
(re-ejecutado), puede ser conveniente apostarle a \m proceso que ha- 
ya hecho poco calculo (para que el tiempo que tenga que invertir 
para volver al punto actual sea minimo). 
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• Mayor tiempo restante estimado. Si se puede estimar cuanto tiempo 
de procesamiento queda pendiente, conviene terminar al proceso que 
mas le falte por hacer. 

• Menor niimero de recursos asignados hasta el momento. Un poco 
como criterio de justicia, y otro poco partiendo de que es un proceso 
que esta haciendo menor uso del sistema. 

• Prioridad mas baja. Cuando hay un ordenamiento de procesos o 
usuarios por prioridades, siempre es preferible terminar un proceso 
de menor prioridad o perteneciente a un usuario poco importante 

que uno de mayor prioridad. 

• En caso de contar con la informacion necesaria, es siempre mejor in- 
terrumpir vn proceso que pueda ser repetido sin perdida de informacion 
que uno que la cause. Por ejemplo, es preferible interrumpir ima 
compilacion que la actualizacion de una base de datos. 

Un punto importante a considerar es cada cuanto debe realizarse la verifi- 
cacion de bloqueos. Podria hacerse: 

■ Cada vez que im proceso solicite im recurso, pero esto Uevaria a im gasto 
de tiempo en este analisis demasiado frecuente. 

■ Con una periodicidad fija, pero esto arriesga a que los procesos pasen 
mas tiempo bloqueados. 

■ Cuando el nivel del uso del CPU baje de cierto porcentaje. Esto indicaria 
que hay un nivel elevado de procesos en espera. 

■ Una estrategia combinada. 

Por ultimo, si bien los dispositivos aqui mencionados requieren bloqueo ex- 
clusivo, otra estrategia es la apropiacion temporal: tomar un recurso asignado a 
determinado proceso para otorgarselo temporalmente a otro. Esto no siempre es 
posible, y depende fuertemente de la naturaleza del mismo — pero podria, por 
ejemplo, interrumpirse un proceso que tiene asignada (pero inactiva) a una 
impresora para otorgarsela temporalmente a otro que tiene un trabajo corto 
pendiente. Esto ultimo, sin embargo, es tan sensible a detalles de cada clase de 
recursos que rara vez puede hacerlo el sistema operativo — es normalmente he- 
cho de acuerdo entre los procesos competidores, por medio de algiin protocolo 
pre-establecido. 

3.4.4. Algoritmo del avestruz 

Una cuarta Irnea (que, por increible que parezca, es la mas comiin, emplea- 
da en todos los sistemas operativos de proposito general) es el llamado algo- 
ritmo del avestruz: ignorar las situaciones de bloqueo (escondiendose de eUas 
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como avestruz que mete la cabeza bajo la tierra), esperando que su ocurrencia 
sea poco frecuente, o si ocurre, que su efecto no repercuta en el sistema. 

Justificando a los avestruces 

Hay que comprender que esto ocurre porque las condiciones impuestas por 
las demas estrategias resultan demasiado onerosas, el conocimiento previo re- 
sulta insuficiente, o los bloqueos simplemente pueden presentarse ante recur- 
sos extemos y no controlados (o conocidos siquiera) por el sistema operativo. 

Ignorar la posibilidad de un bloqueo cuando su probabilidad es suficientemente 
baja sera preferible para los usuarios (y programadores) ante la disyuntiva de 
afrontar restricciones para la forma y conveniencia de solicitar recursos. 

En este caso, se toma una decision entre lo correcto y lo conveniente — vn sis- 
tema operativo formalmente no deberia permitir la posibilidad de que hubiera 
bloqueos, pero la inconveniencia presentada al usuario seria inaceptable. 

Por ultimo, cabe mencionar algo que a lo largo de todo este apartado men- 
cionamos unicamente de forma casual, evadiendo definiciones claras: ^que es 
im recurso? La realidad es que no esta muy bien definido. Se podria, como 
mencionan los ejemplos, hablar de los clasicos recursos de acceso rival y se- 
cuencial: impresoras, cintas, terminales seriales, etc. Sin embargo, tambien se 
pueden ver como recursos a otras entidades administradas por el sistema ope- 
rativo — el espacio disponible de memoria, el tiempo de procesamiento, o in- 
cluso estructuras logicas creadas y gestionadas por el sistema operativo, como 
archivos, semaforos o monitores. Y para esos casos, practicamente ninguno de 
los mecanismos aqui analizados resolveria las caracteristicas de acceso y blo- 
queo necesarias. 

Enfrentando a los avestruces 

La realidad del computo marca que es el programador de aplicaciones 
quien debe prever las situaciones de carrera, bloqueo e inanicion en su codigo 
— el sistema operativo empleara ciertos mecanismos para asegurar la seguri- 
dad en general entre los componentes del sistema, pero el resto recae en las 
manos del programador. 

Una posible salida ante la presencia del algoritmo del avestruz es adoptar un 
metodo defensivo de programar. Un ejemplo de esto seria que los programas 
soliciten un recurso pero, en vez de solicitarlo por medio de una llamada blo- 
queante, hacerlo por medio de una llamada no bloqueante y, en caso de fallar esta, 
esperar un tiempo aleatorio e intentar nuevamente acceder al recurso un mime- 
ro dado de veces, y, tras n intentos, abortar limpiamente el proceso y notificar 
al usuario (evitando un bloqueo mutuo circular indefinido). 

Por otro lado, hay una gran cantidad de aplicaciones de monitoreo en es- 
pacio de usuario. Conociendo el funcionamiento esperable especffico de de- 
terminados programas es posible construir aplicaciones que los monitoreen de 
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una forma inteligente y tomen acciones (ya sea alertar a los administradores o, 
como se revisa en la seccion 3.4.3, deteccion y recuperacion de bloqueos, abortar 
-y posiblemente reiniciar- la ejecucion de aquellos procesos que no puedan 
recuperarse). 

De avestruces, ingenieros y matematicos 

Esta misma contraposicion puede leerse, hasta cierto punto en tono de bro- 
ma, como un smtoma de la tension que caracteriza al computo como profesion: 
la computacion nacio como ciencia dentro de los departamentos de matemati- 
cas en diversas facultades, sin embargo, al pasar de los anos ha ido integrando 
cada vez mas a la ingenieria. Y el campo, una de las areas mas jovenes pero, al 
mismo tiempo, mas proHficas del conocuniento humano, esta en una constan- 
te discusion y definicion: icomo puede describirse mejor a sus profesionales: 
como matematicos, ingenieros, o. . . algima otra cosa? 

La asignacion de recujrsos puede verse desde el punto de vista matemati- 
co: es um problema con un planteamiento de origen, y hay varias estrategias 
distintas (los mecanismos y algoritmos descritos en esta seccion); pueden no 
ser perfectos, pero el problema no ha demostrado ser intratable. Y un bloqueo 
es claramente un error — una situacion de excepcion, inaceptable. Los mate- 
maticos del arbol genealogico academico Uaman a no ignorar este problema, a 
resolverlo sin importar la complejidad computacional. 

Los ingenieros, mas aterrizados en el mundo real, tienen como parte basi- 
ca de su formacion, si, el evitar defectos nocivos, pero tambien consideran el 
calculo de costos, la probabilidad de impacto, los umbrales de tolerancia. . . Pa- 
ra un ingeniero, si un sistema tlpico corre riesgo de caer en un bloqueo mutuo 
con una probabilidad p > 0, dejando inservibles a dos procesos en un sistema, 
pero debe tambien considerar no s61o las fallas en hardware y en los diferentes 
componentes del sistema operativo, sino que en todos los demas programas 
que ejecutan en espacio de usuario, y considerando que prevenir el bloqueo 
conlleva un costo adicional en complejidad para el desarrollo o en rendimiento 
del sistema (dado que perdera tiempo llevando a cabo las verificaciones ante 
cualquier nueva solicitud de recursos), no debe sorprender a nadie que los in- 
genieros se inclinen por adoptar la estrategia del avestruz — claro esta, siempre 
que no haya opcion razonable. 

3.5. Ejercicios 

3.5.1. Preguntas de autoevaluacion 

1. iQue diferencias y similitudes hay entre un programa y un proceso, y 
entre un proceso y wx hilo? 
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2. Un proceso puede estar en uno de cinco estados. Indique cuales son estos 
estados (describiendo brevemente sus caracteristicas) y cuales las transi- 
ciones definidas entre ellos. 

3. Presente un ejemplo de cada uno de los tres patrones de trabajo para 
la paralelizacion de la ejecucion en varios hilos: los patrones jefe/trabajador, 
equipo de trabajo y Imea de ensamblado. 

4. Defina los siguientes conceptos, e ilustre las relaciones entre ellos: 

■ Concurrencia: 

■ Operacion atomica: 

■ Condicion de carrera: 

■ Seccion crftica: 

■ Espera activa: 

5. Resuelva el siguiente planteamiento, empleando multiples hilos que se 
sincronicen exclusivamente por medio de las herramientas presentadas a 
lo largo de este capitulo: 

En \m restaurante de comida rapida, en \m afan de reducir las distraccio- 
nes causadas por las platicas entre los empleados, el dueno decide que 
cada uno de ellos estara en un cubiculo aislado y no pueden comunicarse 
entre si (o con el cliente) mas que mediante primitivas de sincronizacion. 
Tenemos los siguientes procesos y papeles: 

n clientes Cada cliente que llega pide la comida y especifica cualquier 
particularidad para su orden (doble carne, sin picante, con/ sin le- 
chuga, tomate y ceboUa, etc.) Paga lo que le indique el cajero. Espera 
a que le entreguen su pedido, se lo come, y deja ujn. comentario en el 
libro de visitas. 

Un cajero Recibe la orden del cliente. Cobra el dinero antes de que co- 
mience a procesarse la orden. 

Tres cocineros Saca la carne del refrigerador, pone a la carne sobre la 
plancha, le da la vuelta a cada came para que quede bien cocida y la 
pone en una base de pan. Solo puede sacar la carne de la plancha si 
ya tiene una base de pan lista. 

Puede haber mas de im cocinero, pero la estufa s61o tiene espacio 
para dos carnes. jRecuerde evitar que los cocineros pongan mas de 

las que caben! 

Un armador Mantiene suficientes panes (y no demasiados, porque se se- 
can) aderezados y listos para que el cocinero deposite la came. Una 
vez que un pan con carne esta listo, le agrega los ingredientes que 
hagan falta, lo cierra y entrega al cliente. 
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Implemente en pseudocodigo la solucion para este sistema, e identifique 
que patrones de sincronizacion fueron empleados. 

6. Los bloqueos mutuos no solo ociirren en el campo del computo. Identifi- 
que, basandose en las condiciones de Coffman, situaciones de la vida real 
que (de no ser por el ingenio o la impredictibilidad hiraiana) constitui- 
rian bloqueos mutuos. Describa por que considera que se cumple cada 
una de las condiciones. 

7. Suponga un sistema con 14 dispositivos del mismo tipo que requieren 
acceso exclusivo. En este sistema se ejecutaran de forma simultanea cinco 
procesos de larga duracion, cada uno de los cuales requerira el uso de 
cinco de estos dispositivos — tres de ellos desde temprano en la ejecucion 
del proceso, y los dos restantes, apenas por unos segundos y cerca del fin 
de su ejecucion. 

■ Si el sistema implementa una polltica muy conservadora de asigna- 

cion de recursos {serializacion) , ^cuantos dispositivos estaran ociosos 
como minimo y como maximo mientras se mantengan los cinco pro- 
cesos en ejecucion? 

■ Si el sistema implementa \ma polltica basada en el algoritmo del ban- 
quero, ^cual sera el maximo de procesos que puedan avanzar al mis- 
mo tiempo, cuantos dispositivos estaran ociosos como minimo y co- 
mo maximo mientras se mantengan los cinco procesos en ejecucion? 

3.5.2. Temas de investigacion sugeridos 

Sistemas de arranque modemos en sistemas tipo Unix Un tema no directa- 

mente relacionado con el expuesto en este capftulo, pero que puede ligar- 
se con varios de los conceptos aqul abordados, es la gestion del arranque 
del sistema: una vez que el micleo carga y hace un recorrido basico del 
hardware creandose un mapa de como es el sistema en que esta corrien- 
do, tiene que Uevar el equipo a un estado funcional para sus usuarios. 
^Como ocurre esto? 

Tradicionalmente, los sistemas Unix se dividfan entre dos filosoflas de 
arranque (los sistemas SysV y los sistemas BSD). Pero la realidad del 
computo ha cambiado con el tiempo. Tras ima etapa de largas discusio- 
nes al respecto, la mayor parte de las distribuciones estan migrando a 
systemd, desarrollado originalmente por RedHat. 

^Cuales son los planteamientos basicos de los arranques tipo SysV y tipo 
BSD; a que tipo de cambios en la realidad es que se hace referenda; por 
que los esquemas tradicionales ya no son suficientes para los sistemas 
actuales; en que se parecen y en que se diferencian los sistemas clasicos y 
systemd; que ventajas y desventajas conUevan? 
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Problemas adicionales de sincronizacion De todo el libra, es en este capitulo 
en el que mas se trata directamente con codigo. Si bien para presentar 
como casos de ejemplo se emplearon cinco de los casos clasicos (eljardtn 

ornamental, el problema productor-consmnidor, el problema lectores-escritores, 
la cena de losfilosofos y los fumadores compulsivos), hay muchos otros casos 
ampliamente analizados. 

El libra libremente redistribuible The little book of semaphores (Allan Dow- 
ney, 2008) tiene mas de 20 prablemas de sincronizacion, planteados jun- 
to con su implementacion empleando semaforos en el lenguaje Python. 
Prafundizar en alguno de estos problemas adicionales ayudara al apren- 
dizaje de los temas expuestos. 

3.5.3. Lecturas relacionadas 

■ The little book of semaphores 

http : / / greenteapress . com/ semaphores 
Allan Downey (2008); Green Tea Press 

■ Tutorial de hilos de Perl 

http : / /perl doc .perl.org/perlthrtut. html 

John Orwant (1998); The Perl Journal 

■ Python higher level threading interface 

http : / /docs . python . org/ 2 /library /threading . html 

Python Software Foundation (1990-2014); Python 2.7.6 Documentation 

■ Spin Locks & Other Forms of Mutual Exclusion 

http : / / www . cs . f su . edu/ -baker /devices/ notes/ spin lock . html 
Theodore P. Baker (2010); Florida State University 

■ Dining philosophers revisited 

https : //dl . acm .org /citation. cf m?id=1010 91 
Armando R. Gingras (1990), ACM SIGCSE Bulletin 



Capitulo 4 

Planificacion de procesos 



4.1. Tipos de planificacion 

La planificacion de procesos se refiere a como determina el sistema operative 
al orden en que ira cediendo el uso del procesador a los procesos que lo vayan 
solicitando, y a las poHticas que empleara para que el uso que den a dicho 
tiempo no sea excesivo respecto al uso esperado del sistema. 

Hay tres tipos principales de planificacion: 

A largo plazo Decide que procesos seran los siguientes en ser iniciados. Este 
tipo de planificacion era el mas frecuente en los sistemas de lotes (princi- 
palmente aquellos con spool) y multiprogramados en lotes; las decisiones 
eran tomadas considerando los requisitos pre-declarados de los procesos 
y los que el sistema tenia libres al terminar algtin otro proceso. La plani- 
ficacion a largo plazo puede Uevarse a cabo con periodicidad de una vez 
cada varios segundos, minutos e inclusive horas. 

En los sistemas de uso interactivo, casi la totalidad de los que se usan hoy 
en dla, este tipo de planificacion no se efectiia, dado que es tlpicamente 
el usuario quien indica expresamente que procesos iniciar. 




Figura 4.1: Planificador a largo plazo. 



131 



132 



CAPiTUL04. PLANIFICACION DE PROCESOS 



A mediano plazo Decide cuales procesos es conveniente bloquear en determi- 
nado momento, sea por escasez/saturacion de algun recurso (como la 
memoria primaria) o porque estan realizando alguna solicitud que no 
puede satisfacerse momentaneamente; se encarga de tomar decisiones 
respecto a los procesos conforme entran y salen del estado de bloqueado 
(esto es, tipicamente, estan a la espera de algun evento externo o de la 
finalizacion de transferencia de datos con algiin dispositivo). 

En algunos textos, al planificador a mediano plazo se le llama agendador (sche- 
duler). 



Inicio 



Cola de 
procesos listos 



E/S 
mmpletada 



z 




E/S 






Cola de 




entrada/salida 



Figura 4.2: Planificador a mediano plazo, o agendador. 



A corto plazo Decide como compartir momento a momento al equipo entre to- 
dos los procesos que requieren de sus recursos, especiaknente el proce- 
sador. La planificacion a corto plazo se lleva a cabo decenas de veces por 
segundo (razon por la cual debe ser codigo muy simple, eficiente y rapi- 
do); es el encargado de planificar los procesos que estan listos para ejecucidn. 

El planificador a corto plazo es tambien firecuentemente denominado despa- 
chador {dispatcher). 




Figura 4.3: Planificador a corto plazo, o despachador. 
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Relacionando con los estados de un proceso abordados en la seccion 3.1.1, 
y volviendo al diagrama entonces presentado (reproducido por comodidad de 
referenda en la figura 4.4), podrian ubicarse estos tres planificadores en las 
siguientes transiciones entre estados: 



Nuevo 



Admitir 



Listo 




Figura 4.4: Diagrama de transicion entre los estados de un proceso. 

1. El planificador a largo plazo se encarga de admitir iin nuevo proceso: la 
transicion de nuevo a listo. 

2. El planificador a mediano plazo maneja la activacion y bloqueo de un pro- 
ceso relacionado con eventos, esto es, las transiciones entre en ejecucion y 
bloqueado, y entre bloqueado y listo. 

3. El planificador a corto plazo decide entre los procesos que estan listos 
para ejecutarse y determina a cual de ellos activar, y detiene a aquellos 
que exceden su tiempo de procesador — inaplementa las transiciones entre 
los estados listo y en ejecucion. 

En esta seccion se trata particularmente el planificador a corto plazo, hacien- 
do referenda como mucho a algunos efectos del planificador a mediano plazo. 

4.1.1. Tipos de proceso 

Como ya se ha visto, los procesos tipicamente alteman entre rdfagas (perio- 
dos, en ingles bursts) en que realizan. principalmente compute interno (estan li- 
mitados por CPU, CF\J-bound) y otras, en que la atencion esta puesta en transmitir 
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los datos desde o hacia dispositivos externos (estan limitados por entrada-salida, 
I/O-bound). Dado que cuando un proceso se suspende para realizar entrada- 
salida deja de estar listo (y pasa a estar bloqueado), y desaparece de la atencion 
del planificador a corto plazo, en todo momento los procesos que estan en eje- 
cucion y listos pueden separarse en: 

Procesos largos Aquellos que por mucho tiempo^ han estado en listos o en eje- 
cucion, esto es, procesos que esten en una larga rafaga limitada por CPU. 

Procesos cortos Los que, ya sea que en este momento^ esten en una rafaga li- 
mitada por entrada-salida y requieran atencion meramente ocasional del 
procesador, o tienden a estar bloqueados esperando a eventos (como los 
procesos interactivos). 

Por lo general se busca dar un tratamiento preferente a los procesos cortos, 
en particular a los interactivos. Cuando un usuario esta interactuando con un 
proceso, si no tiene una respuesta inmediata a su interaccion con el equipo (sea 
proporcionar comandos, recibir la respuesta a \m teclazo o mover el puntero en 
el GUI) su percepcion sera la de una respuesta degradada. 

4.1.2. Midiendo la respuesta 

Resulta intuitivo que cada patron de uso del sistema debe seguir poHticas 
de planificacion distintas. Por ejemplo, en el caso de tm proceso interactivo, 
se buscara ubicar al proceso en una cola preferente (para obtener un tiempo 
de respuesta mas agil, para mejorar la percepcion del usuario), pero en caso 
de sufrir demoras, es preferible buscar dar tma respuesta consistente, aiin si 
la respuesta promedio es mas lenta. Esto es, si a todas las operaciones sigue 
una demora de un segundo, el usuario sentira menos falta de control si en 
promedio tardan medio segundo, pero ocasionalmente hay picos de cinco. 

Para este tema, en vez de emplear unidades temporales formales (p. ej. frac- 
ciones de segundo), es comun emplear ticks y quantums. Esto es en buena me- 
dida porque, si bien en el campo del compute las velocidades de acceso y uso 
efectivo cambian constantemente, los conceptos y las definiciones permane- 
cen. Ademas, al ser ambos parametros ajustables, una misma implementacion 
puede sobrevivir ajustandose a la evolucion del hardware. 

Tick Una fraccion de tiempo durante la cual se puede realizar trabajo util, esto 
es, usar el CPU sin interrupcion^. El tiempo correspondiente a un tick 
esta determinado por una serial (interrupcion) periodica, emitida por el 
temporizador (timer). La frecuencia con que ociurre esta senal se establece 

^^Cuanto es mucho? Dependera de las politicas generates que se definan para el sistema. 

tambien, este momento debe ser interpretado con la granularidad acorde al sistema. 
^Ignorando las interrupciones causadas por los dispositivos de entrada y saUda y otras sefiales 
que llegan al CPU. 
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al inicio del sistema. For ejemplo, una frecuencia de temporizador de 100 
Hertz implica que este emitira una senal cada 10 milisegundos. En Linux 
(a partir de la version 2.6.8), un tick dura \m miliseguxido, en Windows, 
entre 10 y 15 milisegimdos. 

Quantum El tiempo minimo que se permitira a un proceso el uso del proce- 

sador. En Windows, dependiendo de la clase de proceso que se trate, un 
quantum durara entre 2 y 12 ticks (esto es, entre 20 y 180 ms), y en Linux, 
entre 10 y 200 ticks (10 y 200 milisegundos respectivamente). 

^Que mecanismos o metricas se emplean para medir el comportamiento del 
sistema bajo determinado planificador? Partiendo de los siguientes conceptos, 
para uxi proceso p que requiere de un tiempo t de ejecucion: 

Tiempo de respuesta (T) Cuanto tiempo total es necesario para completar el 

trabajo pendiente de un proceso p, incluyendo el tiempo que esta inactivo 
esperando ejecucion (pero esta en la cola de procesos listos). 

Tiempo en espera {E = T — t) Tambien referido como tiempo perdido. Del tiem- 
po de respuesta total, cuanto tiempo p esta listo y esperando ejecutar. 
Desde la optica de p, se desearia que Ep ^ 0 

Proporcion de penalizacion (P = j) Proporcion del tiempo de respuesta en 
relacion al tiempo de uso del procesador (en que proporcion fue pena- 
lizado el proceso). 

Proporcion de respuesta (R = j) Inverso de P. Fraccion del tiempo de res- 
puesta durante la cual p pudo ejecutarse. 

Para hacer referenda a un grupo de procesos con requisitos similares, todos 
ellosrequiriendodeunmismotiempof,seemplear(t),E(t) — T{t) — t,P{t) — 

Ademas de estos tiempos, expresados con relacion al tiempo efectivo de los 
diversos procesos del sistema, es necesario considerar tambien: 

Tiempo nucleo o kernel Tiempo que pasa el sistema en espacio de niicleo, in- 
cluyendo entre otras funciones^ el empleado en decidir e implementar 
la politica de planificacion y los cambios de contexto. Este tiempo no se 
contabiliza cuando se calcula el tiempo del CPU utilizado por un proceso. 

Tiempo de sistema Tiempo que pasa im proceso en espacio nucleo atendiendo 
el pedido de un proceso (syscall). Se incluye dentro del tiempo de uso del 
CPU de un proceso y suele discriminarse del tiempo de usuario. 

■*Estas funciones incluyen principalmente la atenci6n a interrupciones, el servicio a Uamadas al 
sistema, y cubrir diversas tareas admlnistratlvas. 
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Tiempo de usuario Tiempo que pasa un proceso en modo usuario, es decir, 
ejecutando las instrucciones que forman parte explicita y directamente 
del programa. 

Tiempo de uso del procesador Tiempo durante el cual el procesador ejecuto 
instrucciones por cuenta de un proceso (sean en modo usuario o en modo 
nucleo). 

Tiempo desocupado (idle) Tiempo en que la cola de procesos listos esta vada 
y no puede realizarse ningiin trabajo. 

Utilizacion del CPU Porcentaje del tiempo en que el CPU esta realizando tra- 
bajo util. Si bien conceptualmente puede ubicarse dicha utilizacion entre 
0 y 100%, en sistemas reales se ha observado (Silberschatz p:179) que se 
ubica en un rango entre 40 y el 90 por ciento. 

Por ejemplo, si llegan a la cola de procesos listos: 



Proceso 


Ticks 


Llegada 


A 


7 


0 


B 


3 


2 


C 


12 


6 


D 


4 


20 



Si el tiempo que toma al sistema efectuar un cambio de contexto es de un 
tick, y la duracion de cada quantum es de cinco ticks, en un ordenamiento de 
ronda,^ se observaria im resultado como el que ilustra la figura 4.5. 




Figura 4.5: Ejecucion de cuatro procesos con quantums de cinco ticks y cambios de 
contexto de dos ticks. 



^Este mecanismo se presentara en breve, en la seccion 4.2.3. 
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Al considerar al tiempo ocupado por el nucleo como un proceso mas, cuyo 
trabajo en este espacio de tiempo finalizo junto con los demas,^ se obtiene por 
resultado: 



Proceso 


t 


T 


E 


P 


R 


A 


7 


18 


11 


2.57 


0.389 


B 


3 


7 


4 


2.33 


0.429 


C 


12 


26 


14 


2.17 


0.462 


D 


4 


9 


5 


2.25 


0.444 


Promedio util 


6.5 


15 


8.50 


2.31 


0.433 


Nucleo 


6 


32 


26 


5.33 


0.188 


Promedio total 


6.4 


18.4 


12.00 


2.88 


0.348 



Abordando cada proceso, para obtener T se parte del momento en que el 
proceso llego a la cola, no el punto de inicio de la Imea de tiempo. En este caso, 
dado que el nucleo siempre esta en ejecucion, se asiraie que inicio tambien en 0. 

Respecto al patron de llegada y salida de los procesos, se lo maneja tambien 
basado en una relacion: partiendo de una frecuencia a de llegada promedio de 
nuevos procesos a la cola de procesos listos, y el tiempo de servicio requerido 
promedio /5, se define el valor de saturacion p como p = ^■ 

Cuando p — 0, nunca Uegan nuevos procesos, por lo cual el sistema esta- 
ra eventualmente desocupado. Cuando p — 1, los procesos son despachados al 
mismo ritmo al que van llegando. Cuando p > 1, el ritmo de llegada de proce- 
sos es mayor que la velocidad a la cual la computadora puede darles servicio, 
con lo cual la cola de procesos listos tendera a crecer (y la calidad de servicio, 
la proporcion de respuesta R, para cada proceso se decrementara). 

4.2. Algoritmos de planificacion 

El planificador a corto plazo puede ser invocado cuando un proceso se en- 
cuentra en algunas de las cuatro siguientes circunstancias: 

1. Pasa de estar ejecutando a estar en espera (por ejemplo, por solicitar una 
operacion de E/S, esperar a la sincronizacion con otro proceso, etcetera). 

2. Pasa de estar ejecutando a estar listo (por ejemplo, al ocurrir la interrupcion 
del temporizador, o de algiin evento extemo). 

3. Deja de estar en espera a estar listo (por ejemplo, al finalizar la operacion 
de E/S que solicito). 

4. Finaliza su ejecucion, y pasa de ejecutando a terminado. 

^Normalmente no se considera al nlicleo al hacer este cMculo, dado que en este ^mbito todo el 
trabajo que hace puede verse como burocracia ante los resultados deseados del sistema. 
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En el primer y cuarto casos, el sistema operative siempre tomara el con- 
trol/ un sistema que opera bajo muUitarea apropiativa implementara tambien el 
segundo y tercer casos, mientras que uno que opera bajo multitarea cooperativa 
no necesariamente reconocera dichos estados. 

Ahora, para los algoritmos a continuacion, cabe recordar que se trata lini- 
camente del despachador. Un proceso siempre abandonara la cola de procesos 
listos al requerir de un servicio del sistema. 

Para todos los ejemplos que siguen, los tiempos estan dados en ticks; no es 
relevante a cuanto tiempo de reloj estos equivalen, sino el rendimiento relativo 
del sistema entero ante una carga dada. 

La presente seccion esta basada fuertemente en el capltulo 2 de An operating 
systems vade mecum (Raphael Finkel, 1988). 

4.2.1. Objetivos de la planificacion 

Los algoritmos que seran presentados a continuacion son respuestas que 
intentan, de diferentes maneras y desde distintos supuestos base, darse a los 
siguientes objetivos principales (tomando en cuenta que algunos de estos ob- 
jetivos pueden ser mutuamente contradictorios): 

Ser justo Debe tratarse de igual manera a todos los procesos que compartan las 
mismas caracteristicas,*^ y nunca postergar indefinidamente uno de ellos. 

Maximizar el rendimiento Dar servicio a la mayor parte de procesos por uni- 
dad de tiempo. 

Ser predecible Un mismo trabajo debe tomar aproximadamente la misma 
cantidad de tiempo en completarse independientemente de la carga del 
sistema. 

Minimizar la sobrecarga El tiempo que el algoritmo pierda en burocracia debe 
mantenerse al mlnimo, dado que este es tiempo de procesamiento litil 
perdido. 

Equilibrar el use de recursos Favorecer a los procesos que empleen recursos 
subutilizados, penalizar a los que peleen por un recurso sobreutilizado 
causando contencion en el sistema. 

Evitar la postergacion indefinida Airaientar la prioridad de los procesos mas 
viejos, para favorecer que alcancen a obtener algiin recurso por el cual 

esten esperando. 

^En el primer caso, el proceso entrara en el dominio del planificador a medium plazo, mientras 
que en el cuarto saldra definitivamente de la lista de ejecucion. 

^Un algoritmo de planificacion puede priorizar de diferente manera a los procesos segtln dis- 
tintos criterios, sin por ello dejar de ser justo, siempre que d6 la misma prioridad y respuesta a 
procesos equivalentes. 
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Favorecer el uso esperado del sistema En un sistema con usuarios interacti- 
vos, maximizar la prioridad de los procesos que sirvan a solicitudes ini- 
ciadas por este (aun a cambio de penalizar a los procesos de sistema ) 

Dar preferencia a los procesos que podrian causar bloqueo Si un proceso de 
baja prioridad esta empleando ujn recurso del sistema por el cual mas 
procesos estan esperando, favorecer que este termine de emplearlo mas 

rapido 

Favorecer los procesos con un comportamiento deseable Si un proceso causa 
muchas demoras (por ejemplo, atraviesa una rafaga de entrada/salida 
que le requiere hacer muchas llamadas a sistema o interrupciones), se le 
puede penaliza porque degrada el rendimiento global del sistema 

Degradarse suavemente Si bien el nivel ideal de utilizacion del procesador 
es al 100%, es imposible mantenerse siempre a este nivel. Un algoritmo 
puede buscar responder con la menor penalizacion a los procesos pre- 
existentes al momento de exceder este irmbral. 

4.2.2. Primero Uegado, primero servido (fcfs) 

El esquema mas simple de planificacion es el primero llegado, primero servido 
(first come, first serve, fcfs). Este es un mecanismo cooperativo, con la minima 
logica posible: cada proceso se ejecuta en el orden en que fue llegando, y hasta 
que suelta el control. El despachador es muy simple, basicamente una cola FIFO. 

Para comparar los distintos algoritmos de planificacion que seran presen- 
tados, se dara el resultado de cada uno de ellos sobre el siguiente juego de 
procesos (Finkel 1988 p:35): 



Proceso 


Tiempo de 
Uegada 


t 


Inicio 


Fin 


T 


E 


P 


A 


0 


3 


0 


3 


3 


0 


1 


B 


1 


5 


3 


8 


7 


2 


1.4 


C 


3 


2 


8 


10 


7 


5 


3.5 


D 


9 


5 


10 


15 


6 


1 


1.2 


E 


12 


5 


15 


20 


8 


3 


1.6 


Promedio 




4 






6.2 


2.2 


1.74 



Si bien un esquema FCFS reduce al mmimo la sobrecarga administrativa (que 
incluye, tanto al tiempo requerido por el planificador para seleccionar al si- 
guiente proceso, como el tiempo requerido para el cambio de contexto), el ren- 
dimiento percibido por los ultimos procesos en llegar (o por procesos cortos 
Uegados en un momento inconveniente) resulta inaceptable. 

Este algoritmo dara servido y salida a todos los procesos siempre que p <1. 
En caso de que se sostenga p > 1, la demora para iniciar la atencion de un 
proceso crecera cada vez mas, cayendo en una cada vez mayor inanicion. 
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Figura 4.6: Primero Uegado, primero servido (FCFS). 



Puede observarse que FCFS tiene caracteristicas claramente inadecuadas pa- 
ra trabajo interactivo, sin embargo, al no requerir de hardware de apoyo (como 
un temporizador) sigue siendo ampliamente empleado. 

4.2.3. Ronda (Round Robin) 

El esquema ronda busca dar una relacion de respuesta buena, tanto para 
procesos largos como para los cortos. La principal diferencia entre la ronda y 
FCFS es que en este caso si emplea multitarea apropiativa: cada proceso que es- 
te en la lista de procesos listos puede ejecutarse por un solo quantum (q). Si un 
proceso no ha terminado de ejecutar al final de su quantum, sera interrumpido 
y puesto al final de la lista de procesos listos, para que espere a su turno nue- 
vamente. Los procesos que sean despertados por los planificadores a mediano o 
largo plazos se agregaran tambien al final de esta lista. 

Con la misma tabla de procesos presentada en el caso anterior (y, por ahora, 
ignorando la sobrecarga administrativa provocada por los cambios de contex- 
to) se obtienen los siguientes resultados: 



Proceso 


Tiempo de 
llegada 


t 


Inicio 


Fin 


T 


E 


P 


A 


0 


3 


0 


6 


6 


3 


2.0 


B 


1 


5 


1 


11 


10 


5 


2.0 


C 


3 


2 


4 


8 


5 


3 


2.5 


D 


9 


5 


9 


18 


9 


4 


1.8 


E 


12 


5 


12 


20 


8 


3 


1.6 


Promedio 




4 






7.6 


3.6 


1.98 



La ronda puede ser ajustada modificando la duracion de q. Conforme se 
incrementa q, la ronda tiende a convertirse en FCFS — si cada quantum es arbi- 
trariamente grande, todo proceso terminara su ejecucion dentro de su quantum; 
por otro lado, conforme decrece q, se tiene una mayor frecuencia de cambios 
de contexto; esto Uevaria a una mayor ilusion de tener un procesador dedicado 
por parte de cada uno de los procesos, dado que cada proceso serla incapaz de 
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notar las rdfagas de atencion que este le da (avance rapido durante un periodo 
corto seguido de uno sin avance). Claro esta, el procesador simulado seria ca- 
da vez mas lento, dada la fuerte penalizacion que iria agregando la sobrecarga 
administrativa. 

Finkel (1988 p:35) se refiere a esto como el principio de la histeresis: hay que 
resistirse al cambio. Como ya se menciono, el algoritmo FCFS mantiene al minimo 
posible la sobrecarga administrativa, y -aunque sea marginalmente- resulta en 
mejor rendimiento global. 

Si se repite el analisis anterior bajo este mismo mecanismo, pero con un 
quantum de cuatro ticks, el resultado es: 



Proceso 


Tiempo de 
llegada 


t 


Inicio 


Fin 


T 


E 


P 


A 


0 


3 


0 


3 


3 


0 


1.0 


B 


1 


5 


3 


10 


9 


4 


1.8 


C 


3 


2 


7 


9 


6 


4 


3.0 


D 


9 


5 


10 


19 


10 


5 


2.0 


E 


12 


5 


14 


20 


8 


3 


1.6 


Promedio 




4 






7.2 


3.2 


1.88 




Figura 4.8: Ronda (Round Robin), con = 4. 



Si bien aumentar el quantum mejora los tiempos promedio de respuesta, au- 
mentarlo hasta convertirlo en un FCFS efectivo degenera en una penalizacion 
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a los procesos cortos, y puede llevar a la inanicion cuando p > 1. Silberschatz 
apunta (p. 188) a que tipicamente el quantum debe mantenerse inferior a la du- 
racion promedio del 80% de los procesos. 

4.2.4. El proceso mas corto a continuacion (spn, shortest pro- 
cess next) 

Cuando no se tiene la posibilidad de implementar multitarea apropiativa, 
pero se requiere de un algoritmo mas justo, contando con informacion por anti- 
cipado acerca del tiempo que reqmeren los procesos que forman la lista, puede 
elegirse el mas corto de los presentes. 

Ahora bien, es muy dificil contar con esta informacion antes de ejecutar el 
proceso. Es mas frecuente buscar caracterizar las necesidades del proceso: ver si 
durante su historia de ejecucion^ ha sido un proceso tendiente a manejar rafa- 
gas limitadas por entrada-salida o limitadas por procesador, y cual es su tendencia 
actual. 

Para estimar el tiempo que requerira un proceso p en su proxima invoca- 
cion, es comiin emplear el promedio exponencial Cp. Se define un factor atenuante 
0 < / < 1, que determinara que tan reactivo sera el promedio obtenido a la 
ultima dujracion; es comiin que este valor sea cercano a 0.9. 

Si el proceso p empleo q quantums durante su ultima invocacion, 

e'p^fep + il-f)q 

Se puede tomar como semilla para el gp inicial un niimero elegido arbitra- 
riamente, o uno que ilustre el comportamiento actual del sistema (como el pro- 
medio del gp de los procesos actualmente en ejecucion). La figura 4.10 presenta 
la prediccion de tiempo requerido que determinado proceso va obteniendo en 
sus diversas entradas a la cola de ejecucion, basado en su comportamiento pre- 
vio, con distintos factores atenuantes. 

Empleando el mismo juego de datos de procesos que se ha venido mane- 
jando como resultados de las estimaciones, se obtiene el siguiente resultado: 



Proceso 


Tiempo de 
Uegada 


t 


Inicio 


Fin 


T 


E 


P 


A 


0 


3 


0 


3 


3 


0 


1.0 


B 


1 


5 


5 


10 


9 


4 


1.8 


C 


3 


2 


3 


5 


2 


0 


1.0 


D 


9 


5 


10 


15 


6 


1 


1.2 


E 


12 


5 


15 


20 


8 


3 


1.6 


Promedio 




4 






5.6 


1.6 


1.32 



Cabe recordar que todos estos mecanismos se aplican al planificador a corto plazo. Cuando un 
proceso se bloquea esperando una operaci6n de E/S, sigue en ejecucibn, y la informacion de con- 
tabilidad del mismo sigue alimentSndose. SPN se "nutre" precisamente de dicha informaci6n de 
contabilidad. 
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Figura 4.9: El proceso mas corto a continuacion (SPN). 

Como era de esperarse, SPN favorece a los procesos cortos. Sin embargo, 
un proceso largo puede esperar mucho tiempo antes de ser atendido, especial- 
mente con valores de p cercanos o superiores a 1 — un proceso mas largo que 
el promedio esta predispuesto a sufrir inanicion. 



5 - 
4 

3 / 












Ultimo quantum 

Prediccion con f=0.9 

Prediccion con f=0.7 

Prediccion con f=0,5 


2 


■ 


m 


■nmhmh 





0 2 4 6 8 10 12 14 

Tiempo 

Figura 4.10: Promedio exponencial (prediccion de proxima solicitud de tiempo) de 
im proceso. 

En un sistema poco ocupado, en que la cola de procesos listos es corta, SPN 
generara resultados muy similares a los de FCFS. Sin embargo, puede observar- 
se en el ejemplo que con solo una permutacion en los cinco procesos ejemplos 
(B y C), los factores de penalizacion a los procesos ejemplo resultaron muy be- 
neficiados. 

SPN apropiativo (PSPN, preemptive shortest process next) 

Finkel (1988 p.:4) apunta que, a pesar de que intuitivamente daria una ma- 
yor ganancia combinar las estrategias de SPN con un esquema de multitarea 
apropiativa, el comportamiento obtenido es muy similar para la amplia ma- 
yoria de los procesos. Incluso para procesos muy largos, este algoritmo no los 
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penaliza mucho mas alia de lo que lo haria la ronda, y obtiene mejores pro- 
medios de forma consistente porque, al despachar primero los procesos mas 
cortos, mantiene la lista de procesos pendientes corta, lo que lleva naturalmen- 
te a menores indices de penalizacion. 

El mas penalizado a continuacion (HPRN, highest penalty ratio next) 

En un sistema que no cuenta con multitarea apropiativa, las alternativas 
presentadas hasta ahora resultan invariabLmente injustas: El uso de FCFS favo- 
rece los procesos largos, y el uso de SPN los cortos. Un intento de llegar a \m 
algoritmo mas balanceado es HPRN. 

Todo proceso inicia su paso por la cola de procesos listos con un valor de 
penalizacion P = 1. Cada vez que es obligado a esperar un tiempo w por otro 
proceso, P se actualiza como P = El proceso que se elige como activo sera 
el que tenga mayor P. Mientras p < 1, HPRN evitara que incluso los procesos 
mas largos sufran inanicion. 

En los experimentos realizados por Finkel, HPRN se sitiia siempre en un 
punto medio entre FCFS y SPN; su principal desventaja se presenta conforme 
crece la cola de procesos listos, ya que P tiene que calcularse para cada imo de 
ellos cada vez que el despachador toma una decision. 

4.2.5. Ronda egoista (SRR, selfish round robin) 

Este metodo busca favorecer los procesos que ya han pasado tiempo eje- 
cutando que a los recien llegados. De hecho, los nuevos procesos no son pro- 
gramados directamente para su ejecucion, sino que se les forma en la cola de 
procesos nuevos, y se avanza unicamente con la cola de procesos aceptados. 

Para SRR se emplean los parametros ayb, ajustables segiin las necesidades 
del sistema. a indica el ritmo segun el cual se incrementara la prioridad de los 
procesos de la cola de procesos nuevos, yb el ritmo del incremento de prioridad 
para los procesos aceptados. Cuando la prioridad de un proceso nuevo alcanza 
a la prioridad de un proceso aceptado, el nuevo se vuelve aceptado. Si la co- 
la de procesos aceptados queda vacfa, se acepta el proceso nuevo con mayor 
prioridad. El comportamiento de SRR con los procesos ejemplo es: 



Proceso 



Tiempo de t Inicio Fin T E 
Uegada 



P 



A 
B 
C 
D 

E 



0 3 0 4 4 1 

1 5 2 10 9 4 
3 2 6 9 6 4 
9 5 10 15 6 1 

12 5 15 20 8 3 



1.3 
1.8 
3.0 
1.2 
1.6 



Promedio 



4 



6.6 2.6 1.79 
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Mientras ^ < 1, la prioridad de un proceso entrante eventualmente alcan- 
zara a la de los procesos aceptados, y comenzara a ejecutarse. Mientras el con- 
trol va alternando entre dos o mas procesos, la prioridad de todos ellos sera la 
misma (esto es, son despachados efectivamente por una simple ronda). 

Incluso cuando | > 1, el proceso en ejecucion terminara, y B sera aceptado. 
En este caso, este esquema se convierte en FCFS. 

Si ^ = 0 (esto es, si = 0), los procesos recien llegados seran aceptados 
inmediatamente, con lo cual se convierte en una ronda. Mientras 0 < | < 1, la 
ronda sera relativamente egoista, dandole entrada a los nuevos procesos incluso 
si los que llevan mucho tiempo ejecutando son muy largos (y, por tanto, su 
prioridad es muy alta). 



4.2.6. Retroalimentacion multinivel (fb, multilevel feedback) 

El mecanismo descrito en la seccion anterior, la ronda egoista, introdujo el 
concepto de tener no una srno varias colas de procesos, que recibiran diferente 
tratamiento. Este mecanismo es muy poderoso, y se emplea en practicamente 
todos los planificadores en uso hoy en dla. Antes de abordar el esquema de 
retroalimentacion multinivel, conviene presentar como opera un sistema con 
multiples colas de prioridad. 

La figura 4.12 ilustra como se presentaria una situacion bajo esta logica: el 
sistema hipotetico tiene cuico colas de prioridad, y siete procesos listos para 
ser puestos en ejecucion. Puede haber colas vaclas, como en este caso la 3. Da- 
do que la cola de mayor prioridad es la 0, el planificador elegira unicamente 
entre los procesos que estan formados en ella: F o C. Solo cuando estos procesos 
terminen (o sean enviados a alguna otra cola), el planificador continuara con 
aquellos que esten en las siguientes colas. 

La retroalimentacion multinivel basa su operacion en mas de una cola — pero 
en este caso, todas ellas tendran el mismo tratamiento general, distinguiendose 
solo por su nivel de prioridad, Cq a C„ . El despachador elegira para su ejecucion 
al proceso que este al frente de la cola de mayor prioridad que tenga algiin pro- 
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Menor prioridad 





4 


Colas 


3 


de 


2 


prioridad 


1 




0 



G * 



Mayor prioridad 



F « 



Figura 4.12: Representacion de nn sistema con cinco colas de prioridad y siete pro- 
cesos listos. 



ceso esperando C,, y tras un numero predeterminado de ejecuciones, lo degrada 
a la cola de prioridad inmediata inferior Q+i. 

El mecanismo de retroalimentacion multinivel favorece los procesos cortos, 
dado que terminaran sus tareas sin haber sido marcados como de prioridades 
inferiores. 

La ejecucion del juego de datos con que han sido presentados los algoritmos 
anteriores bajo este esquema da los siguientes resultados: 



Proceso 


Tiempo de 
llegada 


t 


Inicio 


Fin 


T 


E 


P 


A 


0 


3 


0 


7 


7 


4 


1.7 


B 


1 


5 


1 


18 


17 


12 


3.4 


C 


3 


2 


3 


6 


3 


1 


1.5 


D 


9 


5 


9 


19 


10 


5 


2.0 


E 


12 


5 


12 


20 


8 


3 


1.6 


Promedio 




4 






9 


5 


2.04 



Dado que ahora hay que representar la cola en la que esta cada uno de los 
procesos, en la figura 4.13 se presenta sobre cada una de las Imeas de proceso 
la prioridad de la cola en que se encuentra antes del quantum a iniciar. 

Llama la atencion que practicamente todos los numeros apuntan a que esta 
es una peor estrategia que las presentadas anteriormente — los unicos proce- 
sos beneficiados en esta ocasion son los recien Uegados, que podran avanzar 
al principio, mientras los procesos mas largos seran castigados y podran even- 
tuaLmente (a mayor p) enfrentar inanicion. 

Sin embargo, esta estrategia permite ajustar dos variables: una es la can- 
tidad de veces que un proceso debe ser ejecutado antes de ser degradado a la 
prioridad inferior, y la otra es la duracion del quantum asignado a las colas 
subsecuentes. 

Otro fenomeno digno a comentar es el que se presenta a los ticks 8, 10, 11, 13 
y 14: el despachador interrumpe la ejecucion del proceso activo, para volver a 
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Figura 4.13: Retroalimentacion multinivel (fb) basica. 

cedersela. Esto ocurre porque, efectivamente, concluyo su quantum; idealmen- 
te, el despachador se dara cuenta de esta situacion de inmediato y no iniciara 
un cambio de contexto al mismo proceso. En caso contrario, el trabajo perdido 
por gasto administrativo se vuelve innecesariamente alto. 

El panorama cambia al ajustar estas variables: si se elige un quantum de 2"q, 
donde n es el identificador de cola y qla longitud del quantum base, un proceso 
largo sera detenido por un cambio de contexto al llegar a q, 3q, 7q, 15q, etc., lo 
que llevara al numero total de cambios de contexto a log(^Y^), lo cual resulta 

atractivo frente a los cambios de contexto que tendrla bajo un esquema de 
ronda. 

Tras de estos ajustes ante el juego de procesos con una retroalimentacion 
multinivel con un incremento exponencial al quantum se obtiene como resulta- 
do: 



Proceso 


Tiempo de 
llegada 


t 


Inicio 


Fin 


T 


E 


P 


A 


0 


3 


0 


4 


4 


1 


1.3 


B 


1 


5 


1 


10 


9 


4 


1.8 


C 


3 


2 


4 


8 


5 


3 


2.5 


D 


9 


5 


10 


18 


9 


4 


1.8 


E 


12 


5 


13 


20 


8 


3 


1.6 


Promedio 




4 






7 


3 


1.8 



Los promedios de tiempos de terminacion, respuesta, espera y penalizacion 
para este conjunto de procesos resultan mejores incluso que los de la ronda. 

En este caso, a pesar de que esta estrategia favorece a los procesos recien 
llegados, al tick 3, 9 y 10, llegan nuevos procesos, pero a pesar de estar en la 
cola de mayor prioridad, no son puestos en ejecucion, dado que llegaron a la 
mitad del quantum (largo) de otro proceso. 

Tlpicamente se emplean incrementos mucho mas suaves, y de crecimiento 
mas controlado, como nq o rnlcuso q log(n), dado que en caso contrario un pro- 
ceso muy largo podrla causar muy largas inaniciones para el resto del sistema. 
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0 A 1 



DO 1 





3 R 1 2 
C 0 1 


E 0 1 2 


) 




1 

10 15 20 

^ ^ III 



Figura 4.14: Retroalimentacion multinivel (fb) con q exponencial. 

Para evitar la inanicion, puede considerarse tambien la retroalimentacion 
en sentido inverso: si un proceso largo fue degradado a la cola Cp y pasa deter- 
minado tiempo sin recibir servicio, puede promoverse de nuevo a la cola Cp_i 
para que no sufra inanicion. 

Hoy en dia, muchos de los prrncipales sistemas operativos operan bajo di- 
ferentes versiones de retroalimentacion multinivel, y tipicamente con hasta de- 
cenas de colas. 



4.2.7. Loteria 

Los mecanismos hasta aqul descritos vienen con largas decadas de desa- 
rrollo. Uno de los ultimos algoritmos que ha sido ampliamente difundido en 
unirse a esta lista es el de planificacion por loteria, publicado por Carl Waldspur- 
ger y William Weihl (1994). 

Bajo el esquema de la loteria, cada proceso tiene un numero determinado 
de boletos, y cada boleto le representa una oportunidad de jugar a la loteria. 
Cada vez que el planificador tiene que elegir el siguiente proceso a poner en 
ejecucion, elige un numero al azar^*^, y otorga el siguiente quantum al proceso 
que tenga el boleto ganador. El boleto ganador no es retimdo, esto es, la pro- 
babilidad de que determinado proceso sea puesto en ejecucion no varia entre 
invocaciones sucesivas del planificador. 

Las prioridades pueden representarse en este esquema de forma muy sen- 
cilla: un proceso al que se le quiere dar mayor prioridad simplemente tendra 
mas boletos; si el proceso A tiene 20 boletos y el proceso B tiene 60, sera tres 
veces mas probable que el siguiente turno toque a B que a A. 

El esquema de planificacion por loteria considera que los procesos puedan 
cooperar entre si: si B estuviera esperando un resultado de A, podria transfe- 
rirle sus boletos para aumentar la probabilidad de que sea puesto en ejecucion. 



^'^Si bien operar un generador de niimeros aleatorios en estricto sentido seria demasiado caro 
para un proceso que se ejecuta decenas o cientos de veces por segundo, para jugar a la loteria 
es suficiente emplear un generador debil pseudoaleatorio. El articulo en que este mecanismo fue 
presentado presenta la implementacion del algoritmo Park-Miller, S' = (A x S)mod(2^^ — 1) con 
A = 16 807, implementado en 12 instrucciones de procesador RISC. 
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A pesar de su simplicidad, el esquema de planificacion por loteria resulta 
justo, tanto a procesos cortos, como a largos, y presenta una degradacion muy 
suave incluso en entomos de saturacion. Claro, al derivar de \m proceso aleato- 
rio, resulta imposible presentar una comparacion de este mecanismo abordado 
previamente. 

4.2.8. Esquemas hibridos 

En Imeas generales, los siete algoritmos presentados pueden clasificarse so- 
bre dos discriminadores primarios: si estan pensados para emplearse en multi- 
tarea cooperativa o apropiativa, y si emplean informacion intrinseca a los proce- 
sos evaluados o no lo hacen, esto es, si ujn proceso es tratado de distinta forma 
dependiendo de su historial de ejecucion. 

Cuadro 4.1: Caracterizacion de los mecanismos de planificacion a corto plazo. 





No considera 


Considera 




INTRfNSECA 


INTRfNSECA 


Cooperativa 


Primero llegado 


Proceso mas 




primero servido 


corto (SPN), 




(fcfs) 


Proceso mas 






penalizado (hprn) 


Preventiva 


Ronda (rr) 


Proceso mas corto 




Loteria 


apropiativo (PSPN), 






Retroalimentacion (fb). 






Ronda egoista (SRR) 



Ahora bien, estas caracteristicas primarias pueden ser empleadas en con- 
junto, usando diferentes algoritmos a diferentes niveles, o cambiandolos segiin 
el patron de uso del sistema, aprovechando de mejor manera sus bondades y 
logrando evitar sus deficiencias. A continuacion, algimos ejemplos de esque- 
mas hibridos. 

Algoritmo por cola dentro de FB 

Al introducir varias colas, se abre la posibilidad de que cada una de ellas 
siga un esquema diferente para elegir cual de sus procesos esta a la cabeza. En 
los ejemplos antes presentados, todas las colas operaban siguiendo una ronda, 
pero podria considerarse, por ejemplo, que parte de las colas sean procesadas 
siguiendo una variacion de PSPN que empuje a los procesos mas largos a colas 
que les puedan dar atencion con menor mimero de interrupciones (incluso sin 
haberlos ejecutado aiin). 
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Podria emplearse un esquema SRR para las colas de menor prioridad, sien- 
do que ya tienen procesos que han esperado mucho tiempo para su ejecucion, 
para que -sin que repercutan en el tiempo de respuesta de los procesos cortos 
que van entrando a las colas superiores- terminen lo antes posible su ejecucion. 

Metodos dependientes del estado del sistema 

Los parametros de operacion pueden variar tambien dependiendo del es- 
tado actual del sistema, e incluso tomando en consideracion valores externos 
al despachador. Algunas ideas al respecto son: 

■ Si los procesos listos son en promedio no muy largos, y el valor de satu- 

racion es bajo {p < 1), optar per los metodos que menos sobrecarga ad- 
ministrativa signifiquen, como FCFS o SPN (o, para evitar los peligros de 
la multitarea cooperativa, un rr con un quantum muy largo). Si el despa- 
chador observa que la longitud de la cola excede un valor determinado (o 
muestra una tendencia en ese sentido, al incrementarse p), tendra que cam- 
biar a un mecanismo que garantice una mejor distribucion de la atencion, 
como un RR con quantum corto o PSPN. 

■ Usar un esquema simple de ronda. La duracion de \m quantum puede ser 
ajustada periodicamente (a cada cambio de contexto, o como un calculo 
periodico), para que la duracion del siguiente quantum dependa de la 
cantidad de procesos en espera en la lista, Q = |. 

Si hay pocos procesos esperando, cada uno de ellos recibira un quantum 
mas largo, reduciendo la cantidad de cambios de contexto. Si hay mu- 
chos, cada uno de ellos tendra que esperar menos tiempo para comenzar 
a liberar sus pendientes. 

Claro esta, la duracion de un quantum no debe reducirse mas alia de cierto 
valor mmimo, definido segiin la realidad del sistema en cuestion, dado 
que podria aumentar demasiado la carga burocratica. 

■ Despachar los procesos siguiendo una ronda, pero asignarles una dura- 
cion de quantum proporcional a su prioridad externa (fijada por el usua- 
rio). Un proceso de mayor prioridad ejecutara quantums mas largos. 

■ Peor servicio a continuacion (WSN, worst service next). Es ima generalizacion 
sobre varios de los mecanismos mencionados; su principal diferencia res- 
pecto a HPRN es que no solo se considera penalizacion el tiempo que ha 
pasado esperando en la cola, sino que se considera el mimero de veces 
que ha sido interrumpido por el temporizador o su prioridad externa, y 
se considera (puede ser a favor o en contra) el tiempo que ha tenido que 
esperar por E/S u otros recujrsos. El proceso que ha sufrido del peor servi- 
cio es seleccionado para su ejecucion, y si varios empatan, se elige uno en 
ronda. 
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La principal desventaja de WSN es que, al considerar tantos factores, el 
tiempo requerido, por un lado, para recopilar todos estos datos y, por 
otro, calcular el peso que daran a cada uno de los procesos implicados, 
puede repercutir en el tiempo global de ejecucion. Es posible acudir a 
WSN periodicamente (y no cada vez que el despachador es invocado) pa- 
ra que reordene las colas segiin criterios generales, y abanzar sobre di- 
chas colas con algoritmos mas simples, aunque esto reduce la velocidad 
de reaccion ante cambios de comportamiento. 

■ Algimas versiones historicas de Unix manejaban un esquema en que la 
prioridad especificada por el usuario^^ era matizada y re-evaluada en el 
transcurso de su ejecucion. 

Periodicamente, para cada proceso se calcula una prioridad interna, que 
depende de la prioridad externa (especificada por el usuario) y el tiempo 
consumido recientemente por el proceso. Conforme este recibe mayor 
tiempo de procesador, esta ultima cantidad decrece, y aumenta conforme 
el proceso espera (sea por decision del despachador o por estar en alguna 
espera). 

Esta prioridad interna depende tambien del tamano de la lista de pro- 
cesos listos para su ejecucion: entre mas procesos haya pendientes, mas 
fuerte sera la modificacion que efectiie. 

El despachador ejecutara al proceso que tenga una mayor prioridad des- 
pues de realizar estos pasos, decidiendo por ronda en caso de haber em- 
pates. Claro esta, este algoritmo resulta sensiblemente mas caro compu- 
tacionalmente, aunque mas justo, que aquellos sobre los cuales constru- 
ye. 

4.2.9. Resumiendo 

En esta seccion se presentan algunos mecanismos basicos de planificacion 
a corto plazo. Como se indica en la parte final, es muy poco comiin encontrar 
estos mecanismos en un estado puro — normalmente se encuentra ima combi- 
nacion de ellos, con diferentes parametros segiin el nivel en el cual se esta eje- 
cutando. 

Rendimiento ante diferentes cargas de procesos 

Los algoritmos de esta seccion fueron presentados y comparados ante una 
determinada carga de procesos. No se puede asumir, sin embargo, que su com- 
portamiento sera igual ante diferentes distribuciones: \m patron de trabajo 



^^La lindura, o niceness de im proceso, llamada asf por establecerse por medio del comando nice 
al iniciar su ejecuci6n, o renice xma vez en ejecuci6n 
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donde predominen los procesos cortos y haya unos pocos procesos largos pro- 
bablemente se vera mucho mas penalizado por un esquema SRR (y mucho mas 
favorecido por un SPN o PSPN) que uxio en el cual predominen los procesos 
largos. 




Percentile of time required 

Figura 4.15: Proporcion de penalizacion registrada por cada proceso contra el por- 
centaje del tiempo que 6ste requiere (Finkel p:33). 

Raphael Finkel realize estudios bajo diversas cargas de trabajo, buscando 
comparar de forma significativa estos distintos mecanismos. Finkel simulo el 
comportamiento que estos algoritmos tendrfan ante 50 000 procesos genera- 
dos de forma aleatoria, siguiendo una distribucion exponencial, tanto en sus 
tiempos de Uegada, como en su duracion en ejecucion, y manteniendo como 
parametro de equilibrio un nivel de saturacion p — 0,8 (a — 0,8, fi — 1,0), obte- 
niendo como resultado las figuras aquf reproducidas (4.15 y 4.16) comparando 
algunos aspectos importantes de los diferentes despachadores. 

Duracion minima del quantum 

La penalizacion por cambios de contexto en esquemas apropiativos como la 
ronda puede evitarse empleando quantums mayores. Pero abordando la contra- 
parte, ique tan corto tiene sentido que sea un quantum? Con el hardware y las 
estructuras requeridas por los sistemas operatives de uso general disponibles 
hoy en dfa, un cambio de contexto requiere del orden de 10 microsegundos 
(Silberschatz p:187), por lo que incluso con el quantum de 10 ms (el mas corto 
que manejan tanto Linux como Windows), representa apenas la milesima parte 
del tiempo efectivo de proceso. 

Una estrategia empleada por Control Data Corporation para la CDC6600 
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Percentile of time required 

Figura 4.16: Tiempo perdido contra porcentaje de tiempo requerido por proceso 
(Fmkelp:34). 



(comercializada a partir de 1964, y disenada por Seymour Cray) fue emplear 
hardware especializado que permitiera efectivamente compartir el procesador: 
vn solo procesador tenia 10 juegos de registros, permitiendole altemar entre 10 
procesos con un quantum efectivo igual a la velocidad del reloj. A cada paso 
del reloj, el procesador cambiaba el juego de registros. De este modo, un solo 
procesador de muy alta velocidad para su momento (1 MHz) aparecia ante las 
aplicaciones como 10 procesadores efectivos, cada uno de 100 KHz, reduciendo 
los costos al implementar solamente una vez cada una de las unidades f uncio- 
nales. Puede verse una evoludon de esta idea retomada hacia mediados de la 
decada del 2000 en los procesadores que manejan hilos de ejecucion.^^ 

Esta arquitectura permitia tener multitarea real sin tener que realizar cam- 
bios de contexto, sin embargo, al tener un nivel de concurrencia fijo establecido 
en hardware no es tan facil adecuar a un entomo cambiante, con picos de ocu- 
pacion. 



^^Aunque la arquitecura de la CDC6600 era plenamente superescalar, a diferencia de los proce- 
sadores Hyperthreading, que serd abordada brevemente en la seccion 4.4.4, en que para que dos 
instrucciones se ejecuten simult&ieamente deben ser de naturalezas distintas, no requiriendo am- 
bas de la misma unidad funcional del CPU. El procesador de la CDC6600 no manejaba pipelines, sino 
que cada ejecuci6n empleaba al CPU completo 



154 



CAPiTUL04. PLANIFICACION DE PROCESOS 





(a) Muchos a xmo (b) Uno a tmo (c) Muchos a muchos 

Figura 4.17: Tres modelos de mapeo de hilos a procesos. (Imagenes: Beth Plale; 
v6ase secci6n 4.6.3). 

4.3. Planificacion de hilos 

Ahora bien, tras centrar toda la presente discusion en los procesos, ^como 
caben los hilos en este panorama? Depende de como estos son mapeados a pro- 
cesos a ojos del planificador. 

Como fue expuesto en la seccion 3.2.1, hay dos clases principales de hilo: 
los hilos de usuario o hilos verdes, que son completamente gestionados dentro 
del proceso y sin ayuda del sistema operativo, y los hilos de nucleo o hilos de 
kernel, que si son gestionados por el sistema operativo como si fueran procesos. 
Partiendo de esto, hay tres modelos principales de mapeo: 

Muchos a uno Muchos hilos son agrupados en un solo proceso. Los hilos ver- 
des entran en este supuesto: para el sistema operativo, hay un solo proce- 
so; mientras tiene la ejecucion, este se encarga de repartir el tiempo entre 
sus hilos. 

Bajo este modelo, si bien el codigo escrito es mas portable entre diferentes 
sistemas operativos, los hilos no aprovechan realmente al paralelismo, y 
todos los hilos pueden tener que bloquearse cuando uno solo de eUos 
realiza ima Uamada bloqueante al sistema. 

La figura 4.17(a) Uustra este modelo. 

Uno a uno Cada hilo es ejecutado como un proceso ligero (lightweight process o 
LWP); podrfa dar la impresion de que este esquema desperdicia la prin- 
cipal caracterfstica de los hilos, que es una mayor sencillez y rapidez de 
inicializacion que los procesos, sin embargo, la informacion de estado re- 
querida para crear un LWP es mucho menor que la de un proceso regular, 
y mantiene como ventaja que los hilos contimian. compartiendo su me- 
moria, descriptores de archivos y demas estructuras. 

Este mecanismo permite a los hilos aprovechar las ventajas del parale- 
lismo, pudiendo ejecutarse cada hilo en un procesador distinto, y como 
linica condicion, el sistema operativo debe poder implementar los LWP. 

La esquematizacion de este modelo puede apreciarse en la figura 4.17(b). 
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Muchos a muchos Este mecanismo permite que hayan hilos de ambos mode- 
los: permite hilos unidos {bound threads), en que cada hilo corresponde a 
un (y solo \m) LWP, y de hilos no unidos {unbound threads), de los cuales 
uno 0 mas estaran mapeados a cada LWP. 

El esquema muchos a muchos proporciona las principales caracteristicas 
de ambos esquemas; en caso de ejecutarse en un sistema que no soporte 
mas que el modelo uno a muchos, el sistema puede caer en este como modo 
degradado. Este modelo se presenta en la figura 4.17(c). 

No se detalla en el presente texto respecto a los primeros — cada marco 
de desarrollo o maquina virtual (vease la seccion B.2.1) que emplee hilos de 
usuario actuara cual sistema operativo ante eUos, probablemente con algimo de 
los mecanismos ilustrados anteriormente. 

4.3.1. Los hilos POSIX (pthreads) 

La clasificiacion recien presentada de modelos de mapeo entre hilos y pro- 
cesos se refleja aproximadamente en la categorizacion denominada el dmbito de 
contencion de los hilos POSix (pthreads). 

Hay dos enfoques respecto a la contencion que deben tener los hilos, esto 
es: en el momento que un proceso separa su ejecucion en dos hilos, ^debe cada 
\mo de estos recibir la misma atencion que recibirla \m proceso completo? 

Ambito de contencion de proceso {Process Contention Scope, PCS; en POSix, 
PTHREAD_SCOPE_PROCESS). Una respuesta es que todos los hilos deben 
ser atendidos sin exceder el tiempo que seria asignado a un solo proce- 
so. Un proceso que consta de varios hilos siguiendo el modelo muchos a 
uno, o uno que multiplexa varios hilos no unidos bajo un modelo muchos a 
muchos, se ejecuta bajo este ambito. 

Ambito de contencion de sistema {System Contention Scope, SCS; en POSIX, 
PTHREAD_SC0PE_SYSTEM). Este ambito es cuando, en contraposicion, 
cada hilo es visto por el planificador como un proceso independiente; 
este es el ambito en el que se ejecutarian los hilos bajo el modelo uno a 
uno, o cada uno de los hilos unidos bajo un modelo muchos a muchos, dado 
que los hilos son tratados, para propositos de planificacion, cual procesos 
normales. 

La definicion de pthreads apunta a que, si bien el programador puede 
solicitar que sus hilos sean tratados bajo cualquiera de estos procesos, una im- 
plementacion especifica puede presentar ambos o solo imo de los ambitos. Un 
proceso que solicite que sus hilos sean programados bajo un ambito no imple- 
mentado seran ejecutados bajo el otro, notificando del error (pero permitiendo 
continuar con la operacion). 
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Las implementaciones de pthreads tanto en Windows como en Liniix solo 
consideran SCS. 

Respecto a los otros aspectos mencionados en este capitulo, la especifica- 
cion pthreads incluye funciones por medio de las cuales el programador 
puede solicitar al niicleo la prioridad de cada wxo de los hilos por separado 
(pthread_setschedprio) e incluso pedir el empleo de determinado algo- 
ritmo de planificacion (sched_setscheduler). 

4.4. Planificacion de multiprocesadores 

Hasta este punto, el enfoque de este capitulo se ha concentrado en la pla- 
nificacion asumiendo un solo procesador. Del mismo modo que lo que se ha 
visto hasta este momento, no hay una sola estrategia que pueda ser vista como 
superior a las demas en todos los casos. 

Para trabajar en multiprocesadores, puede mantenerse una sola lista de pro- 
cesos e ir despachandolos a cada uno de los procesadores como imidades de 
ejecucion equivalentes e identicas, o pueden mantenerse listas separadas de 
procesos. A continuacion se presentan algunos argumentos respecto a estos 
enfoques. 

4.4.1. Afinidad a procesador 

En \m entomo multiprocesador, despues de que un proceso se ejecuto por 
cierto tiempo, tendra parte importante de sus datos copiados en el cache del 
procesador en el que fue ejecutado. Si el despachador decidiera lanzarlo en 
un procesador que no compartiera dicho cache, estos datos tendrlan que ser 
invalidados para mantener la coherencia, y muy probablemente (por localidad de 
referenda) serfan vueltos a cargar al cache del nuevo procesador 

Los procesadores actuales normaLmente tienen disponibles varios niveles 
de cache; si \m proceso es migrado entre dos micleos del mismo procesador, 
probablemente solo haga falta invalidar los datos en el cache mas intemo (LI), 
dado que el cache en chip (L2) es compartido entre los varios micleos del mis- 
mo chip; si un proceso es migrado a un CPU flsicamente separado, sera nece- 
sario invalidar tambien el cache en chip (L2), y mantener linicamente el del 
controlador de memoria (L3). 

Pero dado que la situacion antes descrita varia de una computadora a otra, 
no se puede enunciar una regla general — mas alia de que el sistema operativo 
debe conocer como estan estructurados los diversos procesadores que tiene 
a su disposicion, y buscar realizar las migraciones mas baratas, aquellas que 
tengan lugar entre los procesadores mas cercanos. 

Resulta obvio por esto que un proceso que fue ejecutado en determinado 
procesador vuelva a hacerlo en el mismo, esto es, el proceso tiene afinidad por 
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cierto procesador. Un proceso que preferentemente sera ejecutado en determi- 
nado procesador se dice que tiene afinidad suave por el, pero determinados pa- 
trones de carga (por ejemplo, una mucho mayor cantidad de procesos afines a 
cierto procesador que a otro, saturando su cola de procesos listos, mientras que 
el segundo procesador tiene tiempo disponible) pueden Uevar a que el despa- 
chador decida activarlo en otro procesador. 

Por otro lado, algunos sistemas operativos ofrecen la posibilidad de decla- 
rar afinidad dura, con lo cual se garantiza a un proceso que siempre sera ejecuta- 
do en un procesador, o en un conjunto de procesadores. 

Un entomo NUMA, por ejemplo, funcionara mucho mejor si el sistema que 
lo emplea maneja tanto im esquema de afinidad dura como algoritmos de asig- 
nacion de memoria que le aseguren que un proceso siempre se ejecutara en el 
procesador que tenga mejor acceso a sus datos. 

4.4.2. Balanceo de cargas 

En un sistema multiprocesador, la situacion ideal es que todos los procesa- 
dores esten despachando trabajos a 100% de su capacidad. Sin embargo, ante 
una definicion tan rigida, la realidad es que siempre habra uno o mas proce- 
sadores con menos de 100% de carga, o uno o mas procesadores con procesos 
encolados y a la espera, o incluso ambas situaciones. 

La divergencia entre la carga de cada uno de los procesadores debe ser lo 
mas pequena posible. Para lograr esto, se pueden emplear esquemas de balan- 
ceo de cargas: algoritmos que analicen el estado de las colas de procesos y, de ser 
el caso, transfieran procesos entre las colas para homogeneizarlas. Claro esta, el 
balanceo de cargas puede actuar precisamente en sentido contrario de la afini- 
dad al procesador y, efectivamente, puede reubicar a los procesos con afinidad 
suave. 

Hay dos estrategias primarias de balanceo: por un lado, la migracion activa 
o migracion por empuje (push migration) consiste en una tarea que ejecuta como 
parte del niicleo y periodicamente revisa el estado de los procesadores, y en 
caso de encontrar un desbalance mayor a cierto umbral, empuja a uno o mas 
procesos de la cola del procesador mas ocupado a la del procesador mas libre. 
Linux ejecuta este algoritmo cada 200 milisegundos. 

Por otro lado, esta la migracion pasiva o migracion por jalon {pull migra- 
tion). Cuando algun procesador queda sin tareas pendientes, ejecuta al proceso 
especial desocupado (idle). Ahora, el proceso desocupado no significa que el proce- 
sador detenga su actividad — ese tiempo puede utilizarse para ejecutar tareas 
del nucleo. Una de esas tareas puede consistir en averiguar si hay procesos en 
espera en algiin otro de los procesadores, y de ser asi, jalarlo a la cola de este 
procesador. 

Ambos mecanismos pueden emplearse -y normalmente lo hacen- en el 
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mismo sistema. Los principales sistemas operatives modernos emplean casi 
siempre ambos mecanismos. 

Como sea, debe mantenerse en mente que todo balanceo de cargas que se 
haga entre los procesadores conllevara una penalizacion en terminos de afini- 
dad al CPU. 

4.4.3. Colas de procesos: ^una o varias? 

En los puntos relatives al multiprocesamiento hasta ahora abordados se 
parte del supuesto que hay una cola de procesos listos por cada procesador. 
Si, en cambio, hubiera una cola global de procesos listos de la cual el siguiente 
proceso a ejecutarse fuera asignandose al siguiente procesador, fuera este cual- 
quiera de los disponibles, podria ahorrarse incluso elegir entre una estrategia 
de migracion por empuje o por jalon — mientras hubiera procesos pendientes, 
estos serlan asignados al siguiente procesador que tuviera tiempo disponible. 

El enfoque de una sola cola, sin embargo, no se usa en ningiin sistema en 
uso amplio. Esto es en buena medida porque un mecanismo asi haria mucho 
mas dificil mantener la afinidad al procesador y restaria flexibilidad al sistema 
complete. 

4.4.4. Procesadores con soporte a hilos hardware 

El termino de hilos como abstraccion general de algo que se ejecuta con ma- 
yor frecuencia y dentro de un mismo proceso puede llevar a una confusion, 
dado que en esta seccion se tocan dos temas relacionados. Para esta subseccion 
en particular, se hace referencia a los hilos en hardware (en ingles, hyperthrea- 
ding) que forman parte de ciertos procesadores, ofreciendo al sistema una casi 
concurrencia adicional. 

Conforme han subido las frecuencias de reloj en el compute mas alia de le 
que perirute llevar al sistema entero como una sola unidad, una respuesta re- 
currente ha side incrementar el paralelisme. Y este no sole se hace preveyende 
cempenentes completes adicienales, sine separande las unidades funcionales de 
un procesador. 

El flujo de una sola instruccion a traves de un procesador simple como el 
MIPS puede ser dividido en cinco secciones principales, creando una estructu- 
ra cenecida come pipeline (tuberia). Idealmente, en todo memento habra una 
instruccion diferente ejecutando en cada una de las secciones del procesador, 
como lo ilustra la figura 4.18. Las secciones en los procesadores MIPS clasicos 
sen: 

■ Recuperacion de la instruccion {Instruction Fetch, IF). 

■ Decodificacion de la instruccion {Instruction Decode, ID). 

■ Ejecucion {Execution, EX). 
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Figura 4.18: Descomposicion de una instruccion en sus cinco pasos clasicos para 
organizarse en un pipeline. 

■ Acceso a datos (mem). 

■ Almacenamiento (Writeback, WB). 

La complejidad de los procesadores actuales ha crecido ya por encima de lo 
aqui delineado (el Pentium 4 tiene mas de 20 etapas), sin embargo se presenta 
esta separacion como base para la explicacion. Un procesador puede iniciar el 
procesamiento de una instruccion cuando la siguiente apenas avanzo la quinta 
parte de su recorrido — de este modo, puede lograr un paralelismo interno, 
manteniendo idealmente siempre ocupadas a sus partes funcionales. 

Sin embargo, se ha observado que un hay patrones recurrentes que interca- 
lan operaciones que requieren servicio de diferentes componentes del procesa- 
dor, o que requieren de la insercion de burbujas porque una unidad es mas lenta 
que las otras — lo cual lleva a que incluso empleando pipelines, un procesador 
puede pasar hasta 50% del tiempo esperando a que haya datos disponibles 
solicitados a la memoria. 

Para remediar esto, varias de las principales familias de procesadores pre- 
sentan a un mismo nucleo de procesador como si estuviera compuesto de dos 
o mas hilos hardware (conocidos en el mercado como hyper-threads). Esto pue- 
de llevar a una mayor utilizacion del procesador, siguiendo patrones como el 
ilustrado en la figura 4.19. 

Hay que recordar que, a pesar de que se presenten como hilos independien- 
tes, el rendimiento de cada uno depende de la secuencia particular de instruc- 
ciones del otro — no puede esperarse que el incremento en el procesamiento 
sea de 2x; la figura presenta varios puntos en que un hilo esta en espera por 
procesador, dado que el otro esta empleando las unidades funcionales que este 
requiere. 

La planificacion de los hilos hardware sale del ambito del presente mate- 
rial, y este tema se presenta linicamente para aclarar un concepto que proba- 
blemente confunda al alumno por su similitud; los hilos en hardware implican 
cuestiones de complejidad tal como el ordenamiento especifico de las rnstruc- 
ciones, prediccion de ramas de ejecucion, e incluso asuntos relativos a la segu- 
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Figura 4.19: Alternando ciclos de computo y espera por memoria, un procesador 
que implementa hilos hardware (hi/perthreaded) se presenta como dos procesado- 
res. 



ridad, dado que se han presentado goteos que permiten a un proceso ejecutando 
en un hilo espiar el estado del procesador correspondiente a otro de los hilos. 
Para abundar al respecto, el ambito adecuado podria ser un texto orientado 
a la construccion de compiladores (ordenamiento de instrucciones, aprovecha- 
miento del paralelismo), o uno de arquitectura de sistemas (estudio del pipeline, 
aspectos del hardware). 

Esta estrategia guarda gran similitud, y no puede evitar hacerse el paralelo, 
con la comparticion de procesador empleada por la CDC6600, presentada en la 
seccion 4.2.9. 



4.5. Tiempo real 

Todos los esquemas de manejo de tiempo hasta este momento se han en- 
focado a repartir el tiempo disponible entre todos los procesos que requieren 
atencion. Es necesario tambien abordar los procesos que requieren garantias de 
tiempo: procesos que para poder ejecutarse deben garantizar el haber tenido 
determinado tiempo de proceso antes de un tiempo llmite. Los procesos con 
estas caracterlsticas se conocen como de tiempo real. 

Hay ejemplos de procesos que requieren este tipo de planificacion a todo 
nivel; los mas comunes son los controladores de dispositivos y los recodifica- 
dores o reproductores de medios (audio, video). La logica general es la misma. 
Para agendarse como un proceso con requisitos de tiempo real, este debe de- 
clarar sus requisitos de tiempo (formalmente, efectuar su reserva de recursos) al 
iniciar su ejecucion o en el transcurso de la misma. Claro esta, siendo que los 
procesos de tiempo real obtienen una prioridad mucho mayor a otros, normal- 
mente se requerira al iniciar el proceso que este declare que durante parte de su 
ejecucion trabajara con restricciones de tiempo real. 
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4.5.1. Tiempo real duro y suave 

Supongase que un dispositivo genera periodicamente determinada canti- 
dad de informacion y la va colocando en un area determinada de memoria 
compartida (en un buffer). Al inicializarse, su controlador declarara al sistema 
operative cuanto tiempo de ejecucion le tomara recoger y procesar dicha infor- 
macion, liberando el buffer para el siguiente ciclo de escritura del dispositivo, y 
la frecuencia con que dicha operacion tiene que ocurrir. 

En vin sistema capaz de operar con garantias de tiempo real, si el sistema 
operative puede garantizar que en ese intervalo le otorgara al proceso en cues- 
tion suficiente tiempo para procesar esta informacion, el proceso se ejecuta; en 
caso contrario, recibe vn error antes de que esto ocurra por medio del cual podra 
alertar al usuario. 

Los sistemas en que el tiempo maximo es garantizable son conocidos como 
de tiempo real duro. 

La necesidad de atencion en tiempo real puede manejarse periodica (por 
ejemplo, requiero del procesador por 30 ms cada segundo), o aperiodica, por ocu- 
rrencia unica (necesito que este proceso, que tomard 600 ms, termine de ejecutarse en 
menos de 2 segundos). 

Realizar una reserva de recursos requiere que el planificador sepa con certe- 
za cuanto tiempo toma realizar las tareas de sistema que ocurriran en el perio- 
do en cuestion. Cuando entran en juego algunos componentes de los sistemas 
de proposito general que tienen una latenda con variaciones impredecibles (co- 
mo el almacenamiento en disco o la memoria virtual) se vuelve imposible man- 
tener las garantias de tiempo ofrecidas. Por esta razon, en un sistema operative 
de proposito general empleando hardware estandar no es posible implementar 
tiempo real duro. 

Para solventar necesidades como las expresadas en sistemas de uso general, 
el tiempo real suave sigue requiriendo que los procesos criticos reciban \m trato 
prioritario por encima de los processes cemunes; agendar un proceso con esta 
prioridad puede Uevar a la inanicion de procesos de menor prioridad y un 
comportamiento que bajo ciertas metricas resultaria injusto. Un esquema de 
tiempo real suave puede implementarse mediante un esquema similar al de la 
retroalimentacidn multinivel, con las sigmentes particiilaridades: 

■ La cola de tiempo real recibe prioridad sobre todas las demas colas. 

■ La prioridad de un proceso de tiempo real no se degrada conforme se eje- 
cuta repetidamente. 

■ La prioridad de los demas procesos nunca llegan a subir al nivel de tiempo 
real por un proceso automatico (aimque si puede hacerse por una Uama- 
da explfcita). 

■ La latencia de despacho debe ser minima. 
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Casi todos los sistemas operativos en uso amplio hoy en dia ofirecen facili- 
dades basicas de tiempo real suave. 

4.5.2, Sistema operative interrumpible (prevenible) 

Para que la implementacion de tiempo real suave sea apta para estos requi- 
sitos es necesario modificar el comportamiento del sistema operativo. Cuando 
un proceso de usuario hace una llamada al sistema, o cuando una interrupcion 
corta el flujo de ejecucion, hace falta que el sistema procese completa la ruti- 
na que da servicio a dicha solicitud antes de que continue operando. Se dice 
entonces que el sistema operativo no es prevenible o no es interrumpible. 

Para lograr que el niicleo pueda ser interrumpido para dar el control de 
vuelta a procesos de usuario, un enfoque fue el poner puntos de interrupcion en 
los puntos de las funciones del sistema donde fuera seguro, tras asegujrarse que 
las estructuras estaban en un estado estable. Esto, sin embargo, no modifica 
mucho la situacion porque estos puntos son relativamente pocos, y es muy 
difkil reestructurar su logica para permitir puntos de prevencion adicionales. 

Otro enfoque es hacer al niicleo entero completamente interrumpible, ase- 
gurandose de que, a lo largo de todo su codigo, todas las modificaciones a las 
estructuras intemas esten protegidas por mecanismos de sincronizacion, como 
los estudiados en la seccion 3.3. Este metodo ralentiza varios procesos del nii- 
cleo, pero es mucho mas flexible, y ha sido adoptado por los diversos sistemas 
operativos. Tiene la ventaja adicional de que permite que haya hilos del niicleo 
ejecutando de forma concurrente en todos los procesadores del sistema. 

4.5.3. Inversion de prioridades 

Un efecto colateral de que las estructuras del niicleo esten protegidas por 
mecanismos de sincronizacion es que puede presentarse la inversion de priori- 
dades. Esto es: 

■ Un proceso A de baja prioridad hace una llamada al sistema, y es inte- 
rrumpido a la mitad de dicha llamada. 

■ Un proceso B de prioridad tiempo real hace una segunda llamada al sis- 
tema, que reqmere de la misma estructura que la que tiene bloqueada 
A. 

Al presentarse esta situacion, B se quedara esperando hasta que A pueda 
ser nuevamente agendado — esto es, un proceso de alta prioridad no podra 
avanzar hasta que vno de baja prioridad libere su recurso. 

La respuesta introducida por Solaris 2 a esta situacion a este fenomeno es 
la herencia de prioridades: todos los procesos que esten accesando (y, por tanto, 
bloqueando) recursos requeridos por un proceso de mayor prioridad, seran 
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tratados como si fueran de la prioridad de dicho recurso hasta que terminen de 
utilizar el recurso en cuestion, tras lo cual volveran a su prioridad nativa. 

4.6. Ejercicios 

4.6.1. Preguntas de autoevaluacion 

1. En un sistema interactive, los procesos tipicamente estan en ejecucion 
un largo periodo (entre minutes y dias), sin embargo, en el transcurso 
del capltulo estos fueron casi siempre tratados como procesos cortos. iQxxe 
significa esto? ^Cual seria im ejemplo de proceso largo? 

2. Asiimiendo los siguientes procesos: 

Proceso Llegada t 

0 8~ 

B 2 13 

C 4 3 

D 4 6 

E 6 8 

F 6 3 

DesarroUe la representacion grafica de como el despachador les asignaria 
el CPU, y la tabla de analisis, bajo: 

■ Ronda con q — 1 

■ Ronda con q — 3 

■ Proceso mas corto a continuacion 

■ Retroalimentacion multinivel con q — l,n — lyQ — nq 

Compare el rendimiento bajo cada imo de estos esquemas. iQue ventajas 
presenta cada imo? 

3. iCuales de los algoritmos estudiados son mas susceptibles a la inanicion 
que se presenta cuando p > 1? ^Cuales menos? Identifique por lo menos 
dos en cada caso. 

4. Evaliie al planificador por loterta (seccion 4.2.7). 

■ iComo se compararia este metodo con los otros abordados? 

■ ^Para que tipo de carga es mas apto y menos apto? 

■ iQue tan susceptible resulta a producir inanicion? 

■ iQue tan /Msffl seria su ejecucion? 
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■ ^Que modificaciones requeriria para planificar procesos con necesi- 
dades de tiempo real? 

5. Tanto la afinidad a procesador como el balanceo de cargas son elementos 
importantes y deseables en todo planificador que se ejecute en un en- 
tomo multiprocesador. Sin embargo, afinidad y balanceo de cargas tra- 
bajan \mo en contra del otro. ^Por que, cuando debe predominar cada 
uno? 

4.6.2. Temas de investigacion sugeridos 

Planificacion en sistemas operatives reales A lo largo del presente capitulo se 

expusieron los principales esquemas base de planificacion, si bien enun- 
ciados muy en llneas generales. Se menciono tambien que muchos de 
estos esquemas pueden emplearse de forma hibrida, y que su comporta- 
miento puede ser parametrizado llevando a resultados muy distintos. 

Saliendo de la teoria hacia el terreno de lo aplicado, elija dos sistemas 
operativos en uso relativamente comun en ambientes de produccion, y ave- 
rigiie que mecanismos de planificacion emplean. 

lA cuales de los esquemas presentados se parece mas? Los sistemas eva- 
luados, ^ofrecen al usuario o administrador alguna interfaz para cambiar 
el mecanismo empleado o ajustar sus parametros? ^Hay configuraciones 
distintas que puedan emplearse en este ambito para sistemas de escrito- 
rio, embebidos, moviles o servidores? 

Nucleo prevenible, tiempo real y optimizacion fina Los sistemas operativos 
modernos buscan exprimir hasta el ultimo pedacito de rendimiento. Pa- 
ra estudiar como lo hacen, resulta interesante seguir las discusiones (y 
a la implementacion) de Liniix. Los ultimos 10 anos han sido de fuerte 
profesionalizacion y optimizacion. 

Para el tema de planificacion de procesos, un punto muy importante fue 
la introduccion del kernel prevenible (o interrumpible), en 2004. 

^Que significa que el nucleo mismo del sistema operativo puede ser in- 
terrumpido, qmen lo puede interrumpir, que consecuencias tuvo esto, en 
complejidad de codigo y en velocidad? 

Pueden basarse para la preparacion de este tema en un interesante repor- 
te de NIST (Instituto Nacional de Estandares y Tecnologia) de diciembre 
del 2002, Introduction to Linux for Real-Time Control: Introductory Gui- 
delines and Reference for Control Engineers and Managers. Detalla muy 
bien cuales son los requisitos (y las razones detras de ellos) para la imple- 
mentacion de sistemas operativos de tiempo real, e incluye una revision 
del panorama de este campo, muy interesante y muy buen recujso para 
construir desde ahi. 
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Otra referencia muy recomendable al respecto es el articulo de Jonathan 
Corbet, publicado en agosto del 2013 por Linux Weekly News, Optimizing 
preemption. 

Si bien este tema toca principaknente temas de planificacion de proce- 
sos, estos temas van relacionados muy de cerca con los presentados en el 
capitulo 5 y, particularmente, en las secciones 5.3.2 y 5.8.1. 

Las clases de planificacion en Linux y SCHED_DEADLINE En Linux, a partir 
de la version 2.6.23, se usa un mecanismo de planificacion Uamado pla- 

nificador completamente justo {completely fair scheduler). Sin embargo, para 
responder a procesos especificos con necesidades diferentes, Linux man- 
tiene tambien clases de planificacion independientes, las primeras de ellas 
mas pareddas a los mecanismos simples aqui cubiertos: SCHED_RR y 

SCHED_FIFO. 

En marzo del 2014, con el anuncio de la version 3.14 del kernel, fue agre- 
gada la clase SCHED_DEADLINE, principaknente pensada para dar so- 
porte a las necesidades de tiempo real. Esta opera bajo ima logica EDF 

{primer plazo primero, earliest deadline first). 

Ademas de revisar este algoritmo, resulta interesante comprender como 
el sistema da soporte a la mezcla de distintas clases de planificacion en im 
mismo sistema vivo; se sugiere hacer un breve analisis acerca de que tan- 
to EDF (o SCHED_DEADLINE, esta implementacion especlfica) es tiempo 
real suave o dujo. 

Alguxias ligas al respecto: 

■ Articulo en LWN de diciembre de 2013 anticipando la inclusion de 
SCHED_DEADLINE, que presenta los conceptos, e incluye una dis- 
cusion al respecto que puede resultarles interesante y litil. 

■ La pagina de la clase de planificacion SCHED_DEADLINE en Wiki- 
pedia. 

■ La dociraientacion de SCHED_DEADLINE en el micleo de Linux. 

4.6.3. Lecturas relacionadas 

■ Simulation of CPU Process scheduling 

http : / /stimulationof cp . source forge . net/ 

P. A. Krishnan (1999-2009); programa en Java desarrollado para un ciirso 
de Sistemas Operativos, presentando la simiilacion de distintos algorit- 
mos de planificacion. 

■ Thread Scheduling (ctd): quanta, switching and scheduling algorithms 

http : / /www . javamex . com/ tut or ials /threads /thread_scheduling_2 . 

shtml 

Neil Coffey (2013); Javamex tutorial and performance information 



166 



CAPiTUL04. PLANIFICACION DE PROCESOS 



■ Microprocessor Design /Pipelined Processors 

http : / / en . wikibooks . org/wiki/Microprocessor_Design/Pipelined_ 
Processors 

WikiBooks.org (2007-2013) 

■ Thread scheduling and synchronization 

http : / /www . cs . Indiana . edu/ classes /b534-plal/ClassNotes/ sched- synch-details 4 . 

pdf 

Beth Plale (2003); Indiana University 

■ Pdginas de manual de Linux: 

• Hilos POSIX (pthreads) 

http : / /man7 . or g/linux/man-pages /man 7 /pthreads . 7 . html 

• Modificacion del ambito de contencion (pthread_attr_setscope) 

http : / /man7 . or g/linux/man-pages/man3/pthread_attr_set scope . 
3 . html 

• Interfaz para solicitar cambios a los parametros y poHticas de plani- 
ficacion (sched_setscheduler) 

http : //man7 . org/linux/man-pages/man2/ sched_setscheduler . 
2 .html 

■ Windows Internals, 6th edition 

http : //technet .microsoft.com/en-us/sysinternals/bb953901. aspx 
Mark Russinovich, David A. Solomon y Alex lonescu (2012); por Micro- 
soft Press. El capftulo 5 aborda a profundidad los temas de hilos y pro- 
cesos bajo Windows, y esta disponible como ejemplo del libro para su 
descarga en la pagina referida. 

■ Optimizing preemption 

https : //Iwn. net /Articles/5 631 85/ 
Jonathan Corbet (2013), Linux Weekly News 



Capitulo 5 

Administracion de memoria 



5.1. Funciones y operaciones 

El unico espacio de almacenamiento que el procesador puede utilizar di- 
rectamente, mas alia de los registros (que si bien le son intemos y sumamente 
rapidos, son de capacidad demasiado limitada) es la memoria ffsica. Todas las 
arquitecturas de procesador tienen instrucciones para interactuar con la me- 
moria, pero ninguna lo tiene para hacerlo con medios persistentes de almacena- 
miento, como las uiudades de disco. Cabe mencionar que cuando se encuentre 
en un texto referenda al almacenamiento primario siempre se referira a la me- 
moria, mientras que el almacenamiento secundario se refiere a los discos u otros 
medios de aknacenamiento persistente. 

Todos los programas a ejecutar deben cargarse a la memoria del sistema 
antes de ser utilizados. En este capitulo se mostrara como el sistema operativo 
administra la memoria para permitir que varios procesos la compartan — es- 
ta tarea debe preverse desde el proceso de compilacion de los programas (en 
particular, la fase de ligado). Hoy en dfa, ademas, casi todos los sistemas opera- 
tivos emplean implementaciones que requieren de hardware especializado: la 
Unidad de Manejo de Memoria (mmu, por sus siglas en ingles). En el transcurso 
de este capitulo se describira como se manejaban los sistemas multitarea antes 
de la ujniversalizacion de las MMU, y que papel juegan hoy en dia. 

En esta primer seccion se presentaran algimos conceptos base que se em- 
plearan en las secciones subsecuentes. 

5.1.1. Espacio de direccionamiento 

La memoria esta estructurada como im arreglo direccionable de bytes. Esto 
es, al solicitar el contenido de una direccion especlfica de memoria, el hardwa- 
re entregara un byte (8 bits), y no menos. Si se requiere hacer una operacion 
sobre bits especlficos, se debera solicitar y ahnacenar bytes enteros. En algimas 
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arquitecturas, el tamano de palabra es mayor — ^por ejemplo, los procesadores 
Alpha incurrian enfallas de alineacion si se solicitaba una direccion de memoria 
no alineada a 64 bits, y toda llamada a direcciones mal alineadas tenia que ser 
atrapada por el sistema operativo, re-alineada, y entregada. 

Un procesador que soporta un espacio de direccionamiento de 16 bits puede 
referirse directamente a hasta 2^^ bytes, esto es, hasta 65 536 bytes (64 kb). Estos 
procesadores fueron comunes en las decadas de 1970 y 1980 — los mas conoci- 
dos incluyen al Intel 8080 y 8085, Zilog z80, MOS 6502 y 6510, y Motorola 6800. 
Hay que recalcar que estos procesadores son reconocidos como procesadores 
de 8 bits, pero con espacio de direccionamiento de 16 bits. El procesador emplea- 
do en las primeras PC, el Intel 8086, manejaba un direccionamiento de 20 bits 
(hasta 1 024 kb), pero al ser una arquitectura real de 16 bits requeria del empleo 
de segmentacion para alcanzar toda su memoria. 

Con la llegada de la era de las computadoras personates, diversos fabricantes 
introdujeron, a mediados de los anos 1980, los procesadores con arquitectura 
de 32 bits. Por ejemplo, la lA-32 de Intel tiene su inicio oficial con el proce- 
sador 80386 (o simplemente 386). Este procesador podia referenciar desde el 
punto de vista teorico hasta 2^^ bytes (4 GB) de RAM. No obstante, debido a 
las limitaciones tecnologicas (y tal vez estrategicas) para producir memorias 
con esta capacidad, tomo mas de 20 anos para que las memorias ampliamente 
disponibles alcanzaran dicha capacidad. 

Hoy en dfa, los procesadores dominantes son de 32 o 64 bits. En el caso de 
los procesadores de 32 bits, sus registros pueden referenciar hasta 4 294 967 296 
bytes (4 gb) de ram, que esta ya dentro de los parametros de lo esperable hoy 
en dla. Una arquitectura de 32 bits sin extensiones adicionales no puede em- 
plear una memoria de mayor capacidad. No obstante, a traves de un mecanis- 
mo llamado PAE (extension de direcciones ffsicas. Physical Address Extension) 
permite extender esto a rangos de hasta 2^-^ bytes a cambio de un nivel mas de 
indireccion. 

Un procesador de 64 bits podria direccionar hasta 18 446 744 073 709 551 616 
hytes (16 Exabytes). Los procesadores comercialmente hoy en dla no ofrecen 
esta capacidad de direccionamiento principalmente por un criterio economico: 
al resultar tan poco probable que exista un sistema con estas capacidades, los 
chips actuales estan limitados a entre 2^° y 2^^ bits — 1 y 256 terabytes. Esta 
restriccion debe segiiir teniendo sentido economico por muchos anos aiin. 

5.1.2. Hardware: la unidad de manejo de memoria (MMU) 

Con la introduccion de sistemas multitarea, es decir, dos o mas programas 
ejecutandose, se vio la necesidad de tener mas de un programa cargado en me- 
moria. Esto conlleva que el sistema operativo junto con informacion del pro- 
grama a ejecutar debe resolver como ubicar los programas en la memoria flsica 
disponible. 



5.2. KB*), EL REGISTRO BASE CONTENDRIA 504 214, YEL REGISTRO LIMITE169 



Luego ha sido necesario emplear mas memoria de la que esta directamente 
disponible, con el proposito de ofrecer a los procesos mas espacio de lo que 
puede direccionar la arquitectura (hardware) empleada. For otro lado, la abs- 
traccion de un espacio virtualmente ilimitado para realizar sus operaciones 
incluso cuando la memoria real es mucho menor a la solicitada y, por ultimo, la 
ilusion de tener un bloque contiguo e ininterrumpido de memoria, cuando en 
realidad puede haber alta fragmentacion. 

Se explicara como la MMU cubre estas necesidades y que mecanismos em- 
plea para lograrlo — y que cuidados se deben conservar, incluso como pro- 
gramadores de aplicaciones en lenguajes de alto nivel, para aprovechar de la 
mejor manera estas funciones (y evitar, por el contrario, que los programas se 
vuelvan lentos por no manejar la memoria correctamente). 

La MMU es tambien la encargada de verificar que un proceso no tenga ac- 
ceso a leer o modificar los datos de otro — si el sistema operativo tuviera que 
verificar cada una de las instrucciones ejecutadas por un programa para evitar 
errores en el acceso a la memoria, la penalizacion en velocidad seria demasiado 
severa.^ 

Una primera aproximacion a la proteccion de acceso se implementa usando 
un registro base y un registro Umite: si la arquitectura ofrece dos registros del 
procesador que solo pueden ser modificados por el sistema operativo (esto es, 
el hardware define la modificacion de dichos registros como una operacion 
privilegiada que requiere estar ejecutando en modo supervisor), la MMU puede 
comparar sin penalidad cada acceso a memoria para verificar que este en el rango 
permitido. 

Por ejemplo, si a un proceso le fue asignado im espacio de memoria de 64 
KB (65 535 bytes) a partir de la direccion 504 214 (492 

5.2. kb*), el registro base contendna 504 214, y el re- 
gistro Umite 

65 535. Si hubiera una instruccion por parte de dicho proceso que solicitara 
una direccion menor a 504 214 o mayor a 569 749 (556 

5.3. kb*), la MMU lanzaria una excepcion o trampa 
interrumpiendo el 

procesamiento, e indicando al sistema operativo que ocurrio una violacion 
de segmento {segmentation fault)? El sistema operativo entonces procederfa a ter- 

de hecho esta demostrado que no puede garantizarse que una veriflcacibn est^tica sea sufi- 
cientemente exhaustiva 

^iPor qu6 de segmental V6ase la secci6n 5.5. 
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minar la ejecucion del proceso, reclamando todos los recursos que tuviera asig- 
nados y notificando a su usuario. 



Espacio 
Libre 



Proceso 3 



Proceso 2 



Proceso 1 



Sistema Operativo 



0x100000 



OxOBAFFF^ 569343 (base+h'mite) 
+ OXOOFFFF +65535 (h'mite) 
•4-0x076000^503808 (base) 



0x040000 
0x020000 



0x000000 



Figura 5.1: Espacio de direcciones validas para el proceso 3 definido por un registro 
base y uno limite. 



5.3.1. La memoria cache 

Hay otro elemento en la actualidad que se asume como un hecho: la memo- 
ria cache. Si bien su manejo es (casi) transparente para el sistema operativo, es 
muy importante mantenerlo en mente. 

Conforme el procesador avanza en la ejecucion de las rnstrucciones (au- 
mentando el valor almacenado en el registro de conteo de instruccion), se pro- 
ducen accesos a memoria. Por un lado, tiene que buscar en memoria la siguien- 
te instruccion a ejecutar Por otro, estas instrucciones pueden requerirle uno o 
mas operadores adicionales que deban ser leidos de la memoria. Por ultimo, la 
instruccion puede requerir guardar su resultado en cierta direccion de memo- 
ria. 

Hace afios esto no era un problema — la velocidad del procesador estaba 
basicamente sincronizada con la del manejador de memoria, y el flujo podia 
mantenerse basicamente estable. Pero conforme los procesadores se fueron ha- 
ciendo mas rapidos, y conforme se ha popularizado el procesamiento en para- 
lelo, la tecnologia de la memoria no ha progresado a la misma velocidad. La 
memoria de alta velocidad es demasiado cara, e incluso las distancias de unos 
pocos centimetros se convierten en obstaculos insalvables por la velocidad ma- 
xima de los electrones viajando por pistas conductoras. 

Cuando el procesador solicita el contenido de una direccion de memoria 
y esta no esta aun disponible, tiene que detener su ejecucion (stall) hasta que los 
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datos esten disponibles. El CPU no puede, a diferencia del sistema operative, 
"congelar" todo y guardar el estado para atender otro proceso: para el pro- 
cesador, la lista de instrucciones a ejecutar es estrictamente secuencial, y todo 
tiempo que requiere esperar una transferencia de datos es tiempo perdido. 

La respuesta para reducir esa espera es la memoria cache. Esta es una memo- 
ria de alta velocidad, situada entre la memoria principal y el procesador propia- 
mente, que guarda copias de las pdginas que van siendo accesadas, partiendo 
del principio de la localidad de referenda: 

Localidad temporal Es probable que un recurso que fue empleado reciente- 
mente vuelva a emplearse en un futuro cercano. 

Localidad espacial La probabilidad de que un recurso aun no requerido sea ac- 
cesado es mucho mayor si fue requerido algiin recurso cercano. 

Localidad secuencial Un recurso, y muy particularmente la memoria, tiende 
a ser requerido de forma secuencial. 

Aplicando el concepto de localidad de referenda, cuando el procesador 
solicita al hardware determinada direccion de memoria, el hardware no solo 
transfiere a la memoria cache el byte o palabra solicitado, sino que transfiere 
\m bloque o pdgina completo. 

Cabe mencionar que hoy en dia (particularmente desde que se detuvo la 
guerra de los Megahertz), parte importante del diferencial en precios de los pro- 
cesadores lideres en el mercado es la cantidad de memoria cache de primero y 
segundo nivel con que cuentan. 

5.3.2. El espacio en memoria de un proceso 

Cuando un sistema operative inicia un proceso, no se limita a volcar el ar- 
chive ejecutable a memoria, sino que tiene que proporcionar la estructura para 
que este vaya guardando la informacion de estado relativa a su ejecucion. 

Seccion (o segmento) de texto Es el nombre que recibe la imagen en memo- 
ria de las instrucciones a ser ejecutadas. UsuaLmente, la seccion de texto 
ocupa las direcciones mas bajas del espacio en memoria. 

Seccion de datos Espacio fijo preasignado para las variables globales y datos 
inicializados (como las cadena de caracteres por ejemplo). Este espacio es 
fijado en tiempo de compilacion, y no puede cambiar (aunque los datos 
que cargados alli si cambian en el tiempo de vida del proceso). 

Espacio de libres Espacio de memoria que se emplea para la asignacion dina- 
mica de memoria durante la ejecucion del proceso. Este espacio se ubica 
por encima de la seccion de datos, y crece hacia arriba. Este espacio es co- 
nocido en ingles como el Heap. 
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Figura 5.2: Patrones de acceso a memoria, demostrando la localidad espacial/ tem- 
poral (Silberschatz p:350). 



Cuando el programa es escrito en lenguajes que requieren manejo dindmi- 
co manual de la memoria (como C), esta area es la que se maneja mediante 
las Uamadas de la familia de malloc y free. En lenguajes con gestion 
automatica, esta area es monitoreada por los recolectores de basura. 



Pila de Uamadas Consiste en un espacio de memoria que se usa para almace- 
nar la secuencia de funciones que han sido Uamadas dentro del proceso, 
con sus parametros, direcciones de retorno, variables locales, etc. La pi- 
la ocupa la parte mas alta del espacio en memoria, y crece hacia abajo. En 
ingles, la pila de Uamadas es denominada Stack. 
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Section de datos 



Seccion de texto 



Figura 5.3: Regiones de la memoria para un proceso. 



5.3.3. Resolucion de direcciones 

Un programa compilado no emplea nombres simbolicos para las variables 
o funciones que llama;'' el compilador, al convertir el programa a lenguaje ma- 
quina, las sustituye por la direccion en memoria donde se encuentra la variable 
o la fimcion.^ 

Ahora bien, en los sistemas actuales, los procesos requieren coexistir con 
otros, para lo cual las direcciones indicadas en el texto del programa pueden 
requerir ser traducidas al lugar relativo al sitio de inicio del proceso en memoria 
— esto es, las direcciones son resueltas o traducidas. Hay diferentes estrategias 
de resolucion, que se pueden clasificar a grandes rasgos^ en: 



En tiempo de compilacion El texto del programa tiene la direccion absoluta de 
las variables y funciones. Esto era muy comiin en las computadoras pre- 
vias al multiprocesamiento. En la arquitectura compatible con PC, el for- 
mato ejecutable . COM es un volcado de memoria directo de un archivo 
objeto con las direcciones indicadas de forma absoluta. Esto puede verse 
hoy principalmente en sistemas embebidos o de funcion especlfica. 

En tiempo de carga Al cargarse a memoria el programa y antes de iniciar su 
ejecucion, el cargador (componente del sistema operativo) actualiza las 
referencias a memoria dentro del texto para que apunten al lugar correc- 



^Cuando se hace ligado dindmico a bibliotecas externas si se mantiene la referenda por nombre, 
pero para los propositos de esta seccion, se habla de las referencias internas linicamente 

^De hecho, una vez que el programa se pasa a lenguaje de maquina, no hay diferencia real entre 
la direccion que ocupa una variable o codigo ejecutable. La diferencia se establece por el uso que 
se de a la referenda de memoria. En la seccion 5.8.1 se abordara un ejemplo de como esto puede 
tener importantes consecuencias. 

^Esta explicacion simplifica muchos detalles; para el lector interesado en profundizar en este 
tema, se recomienda el libro Linkers and Loaders {Ligadores y cargadores) de John R. Levine (1999). 
Esta disponible en linea desde el sitio Web del autor, http:/ /www.iecc. com/linker/ 
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to — claro esta, esto depende de que el compilador indique donde estan 
todas las referencias a las variables y las funciones. 

En tiempo de ejecucion El programa nunca hace referencia a una ubicacion 
absoluta de memoria, sino que lo hace siempre relative a una base y ujn. 
desplazamiento (offset). Esto permite que el proceso sea incluso reubicado 
en la memoria mientras esta siendo ejecutado sin tener que sufrir cam- 
bios, pero requiere de hardware especlfico (como una MMU). 

Esto es, los nombres simbolicos (por ejemplo, una variable Uamada contador) 
para ser traducidos ya sea a ubicaciones en la memoria, pueden resolverse en 
tiempo de compilacion (y quedar plasmada en el programa en disco con una 
ubicacion explicita y definitiva: 510 200), en tiempo de carga (seria guardada 
en el programa en disco como inicio + 5 986 bytes, y el proceso de carga inclui- 
ria sustituirla por la direccion resuelta a la svma del registro base, 504 214, y el 
desplazamiento, 5 986, esto es, 510 200). 

Por ultimo, para emplear la resolucion en tiempo de ejecucion, se mantie- 
ne en las instrucciones a ser ejecutadas por el proceso la etiqueta relativa al 
modulo actual, inicio + 5 986 bytes, y es resuelta cada vez que sea requerido. 

5.4. Asignacion de memoria contigua 

En los sistemas de ejecucion en lotes, as! como en las primeras computado- 
ras personales, solo un programa se ejecutaba a la vez. Por lo que, mas alia de la 
carga del programa y la satisfaccion de alguna eventual Uamada al sistema so- 
Hcitando recursos, el sistema operative no tenia que ocuparse de la asignacion 
de memoria. 

Al nacer los primeros sistemas operatives multitarea, se hizo necesario re- 
solver como asignar el espacio en memoria a diferentes procesos. 

5.4.1. Particion de la memoria 

La primer respuesta, claro esta, es la mas sencilla: asignar a cada programa 
a ser ejecutado un bloque contiguo de memoria de un tamano fijo. En tanto los 
programas permitieran la resolucion de direcciones en tiempo de carga o de 
ejecucion, podrian emplear este esquema. 

El sistema operative emplearfa una region especffica de la memoria del sis- 
tema (tipicamente la region baja — desde la direccion en memoria 0x00000000 
hacia arriba), y una vez terminado el espacio necesario para el micleo y sus 
estructuras, el sistema asigna espacio a cada uno de los procesos. Si la arqui- 
tectura en cuestion permite limitar los segmentos disponibles a cada imo de los 
procesos (por ejemplo, con los registros base y Itmite discutidos anteriormente), 
esto serfa suficiente para alojar en memoria varios procesos y evitar que inter- 
fieran entre sL 
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Desde la perspectiva del sistema operativo, cada uno de los espacios asig- 
nados a un proceso es una particion. Cuando el sistema operativo inicia, toda la 
memoria disponible es vista como un solo bloque, y conforme se van ejecutan- 
do procesos, este bloque va siendo subdividido para satisfacer sus requisitos. 
Al cargar un programa el sistema operativo calcula cuanta memoria va a re- 
querir a lo largo de su vida prevista. Esto incluye el espacio requerido para la 
asignacion dinamica de memoria con la familia de funciones ma Hoc y free. 



Fragmentacion 

Comienza a aparecer cuando mas procesos terminan su ejecucion, y el sis- 
tema operativo libera la memoria asignada a cada imo de ellos. A medida que 
los procesos finalizan, aparecen regiones de memoria disponible, interrumpi- 
das por regiones de memoria usada por los procesos que aiin se encuentran 
activos. 
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Si la computadora no tiene hardware especifico que permita que los proce- 
sos resuelvan sus direcciones en tiempo de ejecucion, el sistema operative no 
puede reasignar los bloques existentes, y aiinque pudiera hacerlo, mover un 
proceso entero en memoria puede resultar una operacion costosa en tiempo de 
procesamiento. 

Al crear ujn. nuevo proceso, el sistema operative tiene tres estiategias segiin 
las cuales podria asignarle uno de los bloques disponibles: 

Primer ajuste El sistema toma el primer bloque con el tamafio suficiente para 
alojar el nuevo proceso. Este es el mecanismo mas simple de implementar 
y el de mas rapida ejecucion. No obstante, esta estrategia puede causar 
el desperdicio de memoria, si el bloque no es exactamente del tamano 
requerido. 

Mejor ajuste El sistema busca entre todos los bloques disponibles cual es el 
que mejor se ajusta al tamano requerido por el nuevo proceso. Esto im- 
plica la revision completa de la lista de bloques, pero permite que los 
bloques remanentes, una vez que se ubico al nuevo proceso, sean tan pe- 
quenos como sea posible (esto es, que haya de hecho un mejor ajuste). 

Peor ajuste El sistema busca cual es el bloque mas grande disponible, y se lo 
asigna al nuevo proceso. Empleando una estrucura de datos como un 
monttculo, esta operacion puede ser incluso mas rapida que la de primer 
espacio. Con este mecanismo se busca que los bloques que queden des- 
pues de otorgarlos a un proceso sean tan grandes como sea posible, de 
cierto modo balanceando su tamano. 

Lafragmentacidn externa se produce cuando hay muchos bloques libres en- 
tie bloques asignados a procesos; \a fragmentacion interna se refiere a la canti- 
dad de memoria dentio de un bloque que nunca se usara — por ejemplo, si el 
sistema operative maneja bloques de 512 bytes y un proceso requiere solo 768 
bytes para su ejecucion, el sistema le entregara dos bloques (1 024 bytes), con 
lo cual desperdicia 256 bytes. En el peor de los casos, con un bloque de n by- 
tes, vn proceso podria soUcitar kn + 1 bytes de memoria, desperdiciando por 
fragmentacion interna n — 1 bytes. 

Segiin analisis estadisticos (Silberschatz, p.289), por cada N bloques asigna- 
dos, se perderan del orden de 0.5N bloques por fragmentacion interna y exter- 
na. 

Compactacion 

Un problema importante que va surgiendo como resultado de esta frag- 
mentacion es que el espacio total libre de memoria puede ser mucho mayor 
que lo que requiere un nuevo proceso, pero al estar fragmentada en muchos 
bloques, este no encontiara ima particion contigua donde ser cargado. 
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Si los procesos emplean resolucion de direcciones en tiempo de ejecucion, 
cuando el sistema operative comience a detectar un alto Indice de fragmenta- 
cion, puede lanzar una operacion de compresion o compactacion. Esta operacion 
consiste en mover los contenidos en memoria de los bloques asignados pa- 
ra que ocupen espacios contiguos, permitiendo unificar varios bloques libres 
contiguos en uno solo. 




Figura 5.5: Compactacion de la memoria de procesos er\ ejecucion. 

La compactacion tiene un costo alto — involucra mover practicamente la 
totalidad de la memoria (probablemente mas de una vez por bloque). 



Intercambio (swap) con el almacenamiento secundario 

Siguiendo de cierto modo la logica requerida por la compactacion se en- 
cuentran los sistemas que utilizan intercambio (swap) entre la memoria primaria 
y secundaria. En estos, el sistema operative puede comprometer mas espacio de 
memoria del que tiene flsicamente disponible. Cuando la memoria se acaba, el 
sistema suspende un proceso (usualmente un proceso "bloqueado") y almace- 
na una copia de su imagen en memoria en almacenamiento secundario para 
luego poder restaurarlo. 

Hay algunas restricciones que observar previo a suspender un proceso. Por 
ejemplo, se debe considerar si el proceso tiene pendiente alguna operacion de 
entrada / salida, en la cual el resultado se debera copiar en su espacio de me- 
moria. Si el proceso resultara suspendido (retirandolo de la memoria princi- 
pal), el sistema operative no tendrla donde continuar almacenando estos datos 
conforme llegaran. Una estrategia ante esta situacion podrla ser que todas las 
operaciones se realicen linicamente a buffers (regiones de memoria de almace- 
namiento temporal) en el espacio del sistema operative, y este las transfiera el 
contenido del buffer al espacio de memoria del proceso suspendido una vez 
que la operacion finalice. 

Esta tecnica se popularize en los sistemas de escritorio hacia finales de los 
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1980 y principios de los 1990, en que las computadoras personales tenlan tlpi- 
camente entre 1 y 8 MB de memoria. 

Se debe considerar que las unidades de disco son del orden de decenas 
de miles de veces mas lentas que la memoria, por lo que este proceso resulta 
muy caro, por ejemplo, si la imagen en memoria de im proceso es de 100 MB, 
bastante conservador hoy en dfa, y la tasa de transferencia sostenida al disco 
de 50 *mb*/s, intercambiar un proceso al disco toma dos segundos. Cargarlo 
de vuelta a la memoria toma otros dos segundos — y a esto debe sumarse el 
tiempo de posicionamiento de la cabeza de lectura/ escritura, especialmente si 
el espacio a emplear no es secuencial y contiguo. Resulta obvio por que esta 
tecnica ha caldo en desuso conforme aumenta el tamano de los procesos. 

5.5. Segmentacion 

Al desarrollar un programa en un lenguaje de alto nivel, el programador 
usualmente no se preocupa por la ubicacion en la memoria ffsica de los dife- 
rentes elementos que lo componen. Esto se debe a que en estos lenguajes las 
variables y funciones son referenciadas por sus nombres, no por su ubicacion^. 
No obstante, cuando se compila el programa para una arquitectura que soporte 
segmentacion, el compilador ubicara a cada una de las secciones presentadas 
en la seccion 5.3.2 en un segmento diferente. 

Esto permite activar los mecanismos que evitan la escritura accidental de 
las secciones de memoria del proceso que no se deberian modificar (aquellas 
que contienen codigo o de solo lectura), y permitir la escritura de aquellas que 
sf (en las cuales se encuentran las variables globales, la pila o stack y el espacio 
de asignacion dinamica o heap). 

Asf, los elementos que conforman un programa se organizan en secciones: 
\ma seccion contiene el espacio para las variables globales, otra seccion contie- 
ne el codigo compilado, otra seccion contiene la tabla de simbolos, etc. 

Luego, cuando el sistema operativo crea un proceso a partir del programa, 
debe organizar el contenido del archivo ejecutable en memoria. Para ello carga 
en memoria algunas secciones del archivo ejecutable (como mfnimo la seccion 
para las variables globales y la seccion de codigo) y puede configurar otras sec- 
ciones como la pila o la seccion de libres. Para garantizar la proteccion de cada 
una de estas secciones en la memoria del proceso, el sistema puede definir que 
cada seccion del programa se encuentra en un segmento diferente, con diferentes 
tipos de acceso. 

La segmentacion es un concepto que se aplica directamente a la arquitectu- 
ra del procesador. Permite separar las regiones de la memoria lineal en segmen- 
tos, cada uno de los cuales puede tener diferentes permisos de acceso, como se 

programar en lenguaje C por ejemplo, un programador puede trabajar a este mismo nivel 
de abstracci6n, puede referirse directamente a las ubicaciones en memoria de sus dates empleando 
aritmetictt de apuntadores. 
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explicara en la siguiente seccion. La segmentacion tambien a}aida a incremen- 
tar la modularidad de un programa: es muy comun que las bibliotecas ligadas 
dindmicamente esten representadas en segmentos independientes. 

Un codigo compilado para procesadores que implementen segmentacion 
siempre generara referencias a la memoria en xm espacio segmmtado. Este tipo 
de referencias se denominan direcciones logicas y estan formadas por un selector 
de segmento y un desplazamiento dentro del segmento. Para interpretar esta di- 
reccion, la MMU debe tomar el selector, y usando algima estructura de datos, 
obtiene la direccion base, el tamano del segmento y sus atributos de protec- 
cion. Luego, aplicando el mecanismo explicado en secciones anteriores, toma 
la direccion base del segmento y le suma el desplazamiento para obtener tma 
direccion lineal flsica. 

La traduccion de una direccion logica a una direccion lineal puede fallar 
por diferentes razones: si el segmento no se encuentra en memoria, ocurrira 
una excepcion del tipo segmento no presente. Por otro lado, si el desplazamien- 
to especificado es mayor al tamano definido para el segmento, ociurrira una 
excepcion del tipo violacion de segmento 



5.5.1. Pennisos 

Una de las principales ventajas del uso de segmentacion consiste en per- 
mitir que cada uno de los segmentos tenga im distinto juego de permisos para 
el proceso en cuestion: el sistema operativo puede indicar, por ejemplo, que el 
segmento de texto (el codigo del programa) sea de lectura y ejecucion, mientras 
que las secciones de datos, libres y pila (donde se almacena y trabaja la infor- 
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macion misma del programa) seran de lectura y escritura, pero la ejecucion 
estara prohibida/ 

De este modo, se puede evitar que un error en la programacion resulte en 
que datos proporcionados por el usuario o por el entorno modifiquen el c6- 
digo que esta siendo ejecutado.^ Es mas, dado que el acceso de ejecucion esta 
limitado a solo los segmentos cargados del disco por el sistema operativo, un 
atacante no podra introducir codigo ejecutable tan fadlmente — tendria que 
cargarlo come un segmento adicional con los permisos correspondientes. 

La segmentacion tambien permite distinguir niveles de acceso a la memo- 
ria: para que un proceso pueda efectuar llamadas al sistema, debe tener acceso 
a determinadas estructuras compartidas del niicleo. Claro esta, al ser memo- 
ria privilegiada, su acceso requiere que el procesador este ejecutando en modo 
supervisor. 

5.5.2. Intercambio parcial 

Un uso muy comun de la segmentacion, particularmente en los sistemas 
de los 1980, era el de permitir que solo ciertas regiones de un programa sean 
intercambiadas al disco: si un programa esta compuesto por porciones de co- 
digo que nimca se ejecutaran aproximadamente al mismo tiempo en sucesion, 
puede separar su texto (e incluso los datos correspondientes) en diferentes seg- 
mentos. 

A lo largo de la ejecucion del programa, algunos de sus segmentos pue- 

den no emplearse por largos periodos. Estos pueden ser enviados al espacio 
de intercambio (swap) ya sea a solicitud del proceso o por iniciativa del sistema 
operativo. 

Rendimiento 

En la seccion 5.4.1, donde se presenta el concepto de intercambio, se explico 
que intercambiar un proceso completo resultaba demasaido caro. Cuando se 
tiene de un espacio de memoria segmentado y, muy particularmente, cuando 
se usan bibliotecas de carga dinamica, la sobrecarga es mucho menor. 

En primer termino, se puede hablar de la cantidad de informacion a in- 
tercambiar: en im sistema que solo maneja regiones contiguas de memoria, 
intercambiar im proceso significa mover toda su informacion al disco. En un 
sistema con segmentacion, puede enviarse a disco cada uno de los segmentos 
por separado, segun el sistema operativo lo juzgue necesario. Podria sacar de 

^Si bien este es el manejo clasico, no es una regla inquebrantable: el codigo automodificable con- 
Ueva importantes riesgos de seguridad, pero bajo ciertos supuestos, el sistema debe permitir su 
ejecucion. Ademas, muchos lenguajes de programacion permiten la metaprogramacion, que requie- 
re la ejecucion de codigo construido en tiempo de ejecucion. 

^Sin embargo, incluso bajo este esquema, dado que la pila de llamadas (stack) debe mantenerse 
como escribible, es comtin encontrar ataques que permiten modificar la direccion de retomo de una 
subrutina, como serd descrito en la secci6n 5.8.1. 
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memoria a alguno de los segmentos, eligiendo no necesariamente al que mas 
estorbe (esto es, el mas grande), sino el que mas probablemente no se utilice: 
emplear el principio de localidad de referenda para intercambiar al segmento 
menos redentemente utilizado (LRU, least recently used). 

Ademas de esto, si se tiene un segmento de texto (sea el codigo programa 
base o alguna de las bibliotecas) y su acceso es de solo lectura, una vez que este 
fue copiado ya al disco, no hace falta volver a hacerlo: se tiene la certeza de que 
no sera modificado por el proceso en ejecucion, por lo que basta marcarlo como 
no presente en las tablas de segmentos en memoria para que cualquier acceso 
ocasione que el sistema operativo lo traiga de disco. 

Por otro lado, si la biblioteca en cuestion reside en disco (antes de ser car- 
gada) como una imagen directa de su representacion en memoria, al sistema 
operativo le bastara identificar el archivo en cuestion al cargar el proceso; no 
hace falta siquiera cargarlo en la memoria principal y guardarlo al area de inter- 
cambio, puede quedar referido directamente al espacio en disco en que reside 
el archivo. 

Claro esta, el acceso a disco sigue siendo una fuerte penalizacion cada vez 
que un segmento tiene que ser cargado del disco (sea del sistema de archivos 
o del espacio de intercambio), pero este mecanismo reduce dicha penalizacion, 
haciendo mas atractiva la flexibilidad del intercambio por segmentos. 



5.5.3. Ejemplificando 

A modo de ejemplo, y conjuntando los conceptos presentados en esta sec- 
cion, si un proceso tuviera la siguiente tabla de segmentos: 

Segmento Inicio Tamafio Permisos Presente 



0 


15 208 


160 


RWX 


si 


1 


1400 


100 


R 


si 


2 


964 


96 


RX 


si 


3 




184 


W 


no 


4 


10 000 


320 


RWX 


sf 



En la coliimna de permisos, R se refiere a lectura, W a escritura y X a ejecu- 
cion. 

Un segmento que ha sido enviado al espacio de intercambio (en este caso, 
el 3), deja de estar presente en memoria y por tanto, no tiene ya direccion de 
inicio registrada. 

El resultado de hacer referenda a las siguientes direcciones y tipos de acce- 
so: 
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Direccion Tipo de Direccion 



logica 


acceso 


fisica 




0-100 


R 


15 308 




2-84 


X 


1048 




2-84 


w 


Atrapada 


: violacion de seguridad 


2-132 


R 


Atrapada 


: desplazamiento fuera de rango 


3-16 


w 


Atrapada 


: segmento faltante 


3-132 


R 


Atrapada 


: segmento faltante; 






violacion de seguridad 


4-128 


X 


10 128 




5-16 


X 


Atrapada 


: segmento invalido 



Cuando se atrapa una situacion de excepcion, el sistema operativo debe 
intervenir. Por ejemplo, la solicitud de un segmento invalido, de un despla- 
zamiento mayor al tamano del segmento, o de un tipo de acceso que no este 
autorizado, tipicamente Uevan a la terminacion del proceso, en tanto que vna 
de segmento faltante (indicando un segmento que esta en el espacio de inter- 
cambio) Uevaria a la suspension del proceso, lectura del segmento de disco a 
memoria, y una vez que este estuviera listo, se permitirla la continuacion de la 
ejecucion. 

En caso de haber mas de una excepcion, como se observa en la solicitud de 
lectura de la direccion 3-132, el sistema debe reaccionar pritnero a la mas severa: 
si como resultado de esa solicitud iniciara el proceso de carga del segmento, 
solo para abortar la ejecucion del proceso al detectarse la violacion de tipo de 
acceso, serla un desperdicio injustificado de recursos. 

5.6. Paginacion 

La fragmentacion externa y, por tanto, la necesidad de compactacion pue- 
den evitarse por completo empleando la paginacion. Esta consiste en que cada 
proceso esta dividio en varios bloques de tamano fijo (mas pequenos que los 
segmentos) llamados pdginas, dejando de requerir que la asignacion sea de un 
area contigua de memoria. Claro esta, esto requiere de mayor espacializacion 
por parte del hardware, y mayor informacion relacionada a cada uno de los 
procesos: no basta solo con indicar donde inicia y termina el area de memo- 
ria de cada proceso, sino que se debe establecer un mapeo entre la ubicacion 
real (ftsica) y la presentada a cada uno de los procesos (logica). La memoria se 
presentara a cada proceso como si fuera de su uso exclusivo. 

La memoria fisica se divide en una serie de marcos (frames), todos ellos del 
mismo tamano, y el espacio para cada proceso se divide en una serie de paginas 
(pages), del mismo tamano que los marcos. La MMU se encarga del mapeo entre 
paginas y marcos mediante tablas de pdginas. 

Cuando se trabaja bajo ima arqmtectiira que maneja paginacion, las direc- 
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clones que maneja el CPU ya no son presentadas de forma absoluta. Los bits 
de cada direccion se separan en un identificador de pdgina y un desplazamiento, 
de forma similar a lo presentado al hablar de resolucion de instrucciones en 
tiempo de ejecucion. La principal diferencia con lo entonces abordado es que 
cada proceso tendra ya no un unico espacio en memoria, sino una multitud de 
paginas. 

El tamano de los marcos (y, por tanto, las paginas) debe ser una potencia de 
dos, de modo que la MMU pueda discernir facilmente la porcion de una direc- 
cion de memoria que se refiere a la pdgina del desplazamiento. El rango varia, 
segiin el hardware, entre los 512 bytes (2^) y 16 MB (2^^); al ser una potencia de 
dos, la MMU puede separar la direccion en memoria entre los primeros m bits 
(referentes a la pagina) y los ultrmos n bits (referentes al desplazamiento). 



Figura 5.7: Pagina y desplazamiento, en un esquema de direccionamiento de 16 
bits y paginas de 512 bytes. 

Para poder realizar este mapeo, la mmu requiere de una estructura de datos 
denominada tabla de paginas (page table), que resuelve la relacion entre paginas 
y marcos, convirtiendo una direccion logica (en el espacio del proceso) en la 
direccion ftsica (la ubicacion en que realmente se encuentra en la memoria del 
sistema). 

Se puede tomar como ejemplo para explicar este mecanismo el esquema 
presentado en la figura 5.9 (Silberschatz p:292). Este muestra un esquema mi- 
niisculo de paginacion: un espacio de direccionamiento de 32 bytes (cinco bits), 
organizado en ocho paginas de cuatro bytes cada una (esto es, la pagina es 
representada con los tres bits mas significativos de la direccion, y el desplaza- 
miento con los dos bits menos significativos). 

El proceso que se presenta tiene una vision de la memoria como la colum- 
na del lado izquierdo: para el proceso hay cuatro paginas, y tiene sus datos 
distribuidos en orden desde la direccion 00 000 (0) hasta la 01 111 (15), aun- 
que en reaHdad en el sistema estas se encuentren desordenadas y ubicadas en 
posiciones no contiguas. 

Cuando el proceso qmere referirse a la letra/, lo hace indicando la direccion 



Direccion especificada — 0001 1101 0111 0010 
Pdgina (7 bits) 



0001110 101110010 
(OxOE) (0x172) 




Desplazamiento (9 bits) 
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Figura 5.8: Esquema del proceso de paginacion, ilustrando el papel de la MMU. 



00 101 (5). De esta direccion, los tres bits mas significativos (001, 1 — y para la 
computadora, lo natural es comenzar a contar por el 0) se refieren a la pagina 
uno, y los dos bits menos significativos (01, 1) indican al desplazamiento dentro 
de esta. 

La MMU verifica en la tabla de paginas, y encuentra que la pagina 1 corres- 
ponde al marco numero 6 (110), por lo que traduce la direccion logica 00 101 
(5) a la fisica 11 001 (26). 

Se puede tomar la paginacion como una suerte de resolucion o traduccion 
de direcciones en tiempo de ejecucion, pero con una base distinta para cada una 
de las paginas. 



5.6.1. Tamano de la pagina 

Ahora, si bien la fragmentadon externa se resuelve al emplear paginacion, 

el problema de la fragmentadon interna persiste: al dividir la memoria en blo- 
ques de longitud preestablecida de 2" bytes, un proceso en promedio desper- 
diciara \ (y, en el peor de los casos, hasta 2" — 1). Multiplicando esto por el 
numero de procesos que estan en ejecucion en todo momento en el sistema, 
para evitar que una proporcion sensible de la memoria se pierda en fragmen- 
tadon interna, se podria tomar como estrategia emplear \m tamano de pagina 
tan pequeno como fuera posible. 

Sin embargo, la sobrecarga administrativa (el tamano de la tabla de pagina- 
cion) en que se incurre por gestionar demasiadas paginas pequenas se vuelve 
una limitante en sentido opuesto: 

■ Las transferencias entre unidades de disco y memoria son mucho mas 
eficientes si pueden mantenerse como recorridos continuos. El controla- 
dor de disco puede responder a solicitudes de acceso directo a memoria 
(DMA) siempre que tanto los fragmentos en disco como en memoria sean 
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Memoria ffslca 

Figura 5.9: Ejemplo (minusculo) de paginacion, con un espacio de direccionamien- 
to de 32 bytes y paginas de cuatro bytes. 

continuos; fragmentar la memoria demasiado jugaria en contra de la efi- 
ciencia de estas solicitudes. 

■ El bloque de control de proceso (pcb) incluye la informacion de memoria. 

Entre mas paginas tenga un proceso (aunque estas fueran muy peque- 
nas), mas grande es su PCB, y mas informacion requerira intercambiar en 
un cambio de contexto. 

Estas consideraciones opuestas apuntan a que se debe mantener el tamano 
de pagina mas grande, y se regulan. con las primeras expuestas en esta seccion. 

Hoy en dia, el tamano habitual de las paginas es de 4 u 8 KB (2^^ o 2^^ bytes). 
Hay algunos sistemas operativos que soportan multiples tamanos de pagina — 
por ejemplo, Solaris puede emplear paginas de 8 KB y 4 MB (2^^ o 2^^ bytes), 
dependiendo del tipo de informacion que se declare que aknacenaran. 

5.6.2. Almacenamiento de la tabla de paginas 

Algunos de los primeros equipos en manejar memoria paginada empleaban 
\m conjimto especial de registros para representar la tabla de paginas. Esto 
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era posible dado que eran sistemas de 16 bits, con paginas de 8 KB (2^^). Esto 
significa que en el sistema habia linicamente ocho paginas posibles (2^), por lo 
que resiiltaba sensato dedicar tin registro a cada una. 

En los equipos actuales, mantener la tabla de paginas en registros resultaria 
claramente imposible: teniendo un procesador de 32 bits, e incluso si se defi- 
niera un tamano de pagina muy grande (por ejemplo, 4 MB), existirlan 1 024 
paginas posibles;^ con un tamano de paginas mucho mas comiin (4 KB, 2^^ by- 
tes), la tabla de paginas llega a ocupar 5 MB.^'^ Los registros son muy rapidos, 
sin embargo, son en correspondencia muy caros. El manejo de paginas mas 
pequenas (que es lo normal), y muy especialmente el uso de espacios de direc- 
cionamiento de 64 bits, harian prohibitivo este enfoque. Ademas, nuevamente, 
cada proceso tiene una tabla de paginas distinta — se haria necesario hacer una 
transferencia de informacion muy grande en cada cambio de contexto. 

Otra estrategia para enfrentar esta situacion es aknacenar la propia tabla de 
paginas en memoria, y apuntar al inicio de la tabla con un juego de registros 
especiales: el registro de base de la tabla de paginas (ptbr, page table base register) y 
el registro de longitud de la tabla de paginas (ptlr, page table length register)}^ De 
esta manera, en el cambio de contexto solo hay que cambiar estos dos regis- 
tros, y ademas se cuenta con un espacio muy amplio para guardar las tablas de 
paginas que se necesiten. El problema con este mecanismo es la velocidad: Se 
estarfa penalizando a cada acceso a memoria con uno — si para resolver una di- 
reccion logica a su correspondiente direccion ffsica hace falta consultar la tabla 
de paginas en memoria, el tiempo efectivo de acceso a memoria se duplica. 

El buffer de traduccion adelantada (tlb) 

La salida obvia a este dilema es el uso de un cache. Sin embargo, mas que 
ujn. cache generico, la MMU utiliza im cache especializado en el tipo de infor- 
maci6n que maneja: el buffer de traduccion adelantada o anticipada. {Translation 
lookaside buffer. El tlb es una tabla asociativa (un hash) en memoria de alta ve- 
locidad, una suerte de registros residentes dentro de la MMU, donde las Haves 
son las paginas y los valores son los marcos correspondientes. De este modo, las 
biisquedas se efectiian en tiempo constante. 

El TLB tipicamente tiene entre 64 y 1 024 entradas. Cuando el procesador 
efectiia un acceso a memoria, si la pagina solicitada esta en el TLB, la MMU 



'4 MB es 2^2 bytes; '^=2^° = \ 024. 

^"1^ —2^ = 1 048 576, cada entrada con un mmimo de 20 bits para la pagina y otros 20 para el 
marco. |La tabla de paginas misma ocuparia 1'280 paginas! 

^'^iPor que es necesario el segundo? Porque es practicamente imposible que un proceso emplee 
su espacio de direccionamiento complete; al indicar el limite maximo de su tabla de pdginas por 
medio del PTLR se evita desperdiciar grandes cantidades de memoria indicando todo el espacio no 
utiilzado. 
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tiene la direccion fisica de inmediato.^^ En caso de no encontrarse la pagina 
en el TLB, la MMU lanza un folio de pagina {page fault), con lo cual consulta de 
la memoria principal cual es el marco correspondiente. Esta nueva entrada es 
agregada al TLB; por las propiedades de localidad de referenda que se presenta- 
ron anteriormente, la probabilidad de que las regiones mas empleadas de la 
memoria durante ujn. area especifica de ejecucion del programa sean cubiertas 
por relativamente pocas entradas del TLB son muy altas. 




Diraccidn 
I6gicn 



Pagina 






Despla- 


zamiento 





TLB 


Pagina 


jviarco 























Marco 


Direccion 






Memoria 


Despla- 
zamiento 


ffsico 


RAM 







Figura 5.10: Esquema de paginacion empleando un buffer de traduccion adelantada 

(TLB). 



Como sea, dado que el TLB es limitado en tamano, es necesario explicitar 
una politica que indique donde guardar las nuevas entradas (esto es, que entra- 
da reemplazar) ima vez que el TLB esta lleno y se produce ujn fallo de pagina. 
Uno de los esquemas mas comimes es emplear la entrada menos recientemen- 
te utilizada (lru. Least Recently Used), nuevamente apelando a la localidad de 
referenda. Esto tiene como consecuencia necesaria que debe haber un meca- 
nismo que contabilice los accesos dentro del TLB (lo cual agrega tanto latencia 
como costo). Otro mecanismo (con obvias desventajas) es el reemplazar una 
pagina al azar. Se explicaran con mayor detalle, mas adelante, algunos de los 
mecanismos mas empleados para este fin, comparando sus puxitos a favor y en 
contra. 



Subdividiendo la tabla de paginas 

Incluso empleando un TLB, el espacio empleado por las paginas sigue sien- 
do demasiado grande. Si se considera un escenario mas frecuente que el pro- 
puesto anteriormente: empleando un procesador con espacio de direcciona- 
miento de 32 bits, y un tamano de pagina estandar (4 KB, 2^^), se tendria 
1 048 576 (2'^'') paginas. Si cada entrada de la pagina ocupa 40 bits^^ (esto es, 
cinco bytes), cada proceso requerirla de 5 MB (cinco bytes por cada una de 

^^Indica Silberschatz (p.295) que el tiempo efectivo de acceso puede ser 10% superior al que 
tomarfa sin emplear paginaci6n. 

^^20 bits identiflcando a la pagina y otros 20 bits al marco; omitiendo aqui la necesidad de alinear 
los accesos a memoria a bytes individuales, que lo aumentarfan a 24. 
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las paginas) solamente para representar su mapeo de memoria. Esto, especial- 
mente en procesos pequenos, resultaria mas gravoso para el sistema que los 
beneficios obtenidos de la paginacion. 

Aprovechando que la mayor parte del espacio de direccionamiento de un 
proceso esta tlpicamente vacio (la pila de llamadas y el heap), se puede subdi- 
vidir el identificador de pagina en dos (o mas) niveles, por ejemplo, separando 
una direccion de 32 bits en una tabla externa de 10, una tabla interna de 10, y el 
desplazamiento de 12 bits. 



Direcciones solicitadas 



837FE31B 



Tabla de 
paginacion externa 
(1 024 entradas de 10 bits) 



FFCOFFFF- 


FFFFFFFFF 


FF800000- 


-FFBFFFFF 


(...) 


83400000- 


-837FFFFF 


83800000- 


-83BFFFFF 


(...) 


DOCOOOOO- 


-OOFFFFFF 


00800000- 


-OOBFFFFF 


00400000- 


-007FFFFF 


00000000- 


-003FFFFF 



Tablas intermedias de la 
tabla de paginacion 
(1 024 entradas de 10 bits 
en cada una de 

las 1 024 tablas) 



Marcos de 

memoria fi'sica 
(Hasta 1 048 576 marcos 
de 12 bits, 4 096 bytes) 



FFFFFOOO— FFFFFFFF 




FFFFFOOO-FFFFFFFF 


(...) 


(...) 


FFF21000— FFF21FFF 


FFF22000— FFF22FFF 


(...) 


FFF21000— FFF21FFF 


FFCOOOOO— FFCOOFFF 


FFF20000-FFF20FFF 




(...) 


837FF000— 837FFFFF 


837FF000— B37FFFFF 


837FE000-837FEFFF 


837FE000-837FEFFF 


/ 


(...) 


837FD000-837FDFFF 


83400000— 83400FFF 


(...) 




00E52000— 00E52FFF 


OOFFFOOO-OOFFFFFF 


00E51000— 00E51FFF 


(...) 


OOE50000-OOE50FFF 


OOESIOOO-OOESIFFF 


(...) 


(...) 


00001000— OOOOIFFF 


OOCOOOOO— OOCOOFFF 


00000000— OOOOOFFF 



Figura 5.11: Paginacion en dos niveles: una tabla externa de 10 bits, tablas inter- 
medias de 10 bits, y marcos de 12 bits (esquema comiSn para procesadores de 32 
bits). 



Este esquema funciona adecuadamente para computadoras con direccio- 
namiento de hasta 32 bits. Sin embargo, se debe considerar que cada nivel de 
paginas conlleva un acceso adicional a memoria en caso de fallo de pagina 
— emplear paginacion jerarqmca con un nivel extemo y vno interno implica 
que un fallo de pagina triplica (y no duplica, como serfa con un esquema de 
paginacion directo) el tiempo de acceso a memoria. Para obtener una tabla de 
paginas manejable bajo los parametros aqui descritos en tm sistema de 64 bits, 
se puede septuplicar el tiempo de acceso (cinco accesos en cascada para frag- 
mentos de 10 bits, y vn tamano de pagina de 14 bits, mas el acceso a la pagina 
destino). 

Otra altemativa es emplear funciones digestoras {hash functions)^^ para ma- 

^*Una fimci6n digestora puede definirse como H : (J — > M, una funci6n que mapea o proyecta al 
conjunto U en un conjunto M mucho menor; una caracterlstica muy deseable de toda funci6n hash 
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pear cada una de las paginas a un espacio muestral mucho mas pequeno. Cada 
pagina es mapeada a una lista de correspondencias simples.^^ 

Un esquema basado en fundones digestoras ofrece caracteristicas muy 
deseables: el tamano de la tabla de paginas puede variar segun crece el uso 
de memoria de un proceso (aunque esto requiera recalcular la tabla con dife- 
rentes parametros) y el numero de accesos a memoria en espacios tan grandes 
come el de un procesador de 64 bits se mantiene mucho mas tratable. Sin em- 
bargo, por la alta frecuencia de accesos a esta tabla, debe elegirse un algoritmo 
digestor muy agil para evitar que el tiempo que tome calcular la posicion en la 
tabla resulte significativo frente a las alternativas. 



5.6.3. Memoria compartida 

Hay muchos escenarios en que diferentes procesos pueden beneficiarse de 
compartir areas de su memoria. Uno de ellos es como mecanismo de comunica- 
cion entre procesos (IPC, inter process communication), en que dos o mas procesos 
pueden intercambiar estructuras de datos complejas sin incurrir en el costo de 
copiado que implicaria copiarlas por medio del sistema operative. 

Otro caso, mucho mas frecuente, es el de compartir codigo. Si un mismo pro- 
grama es ejecutado varias veces, y dicho programa no emplea mecanismos de 
codigo auto-modificable, no tiene sentido que las paginas en que se representa ca- 
da una de dichas instancias ocupe un marco independiente — el sistema opera- 
tive puede asignar a paginas de diversos procesos el mismo conjunto de marcos, 
con lo cual puede aumentar la capacidad percibida de memoria. 

Y si bien es muy comiin compartir los segmentos de texto de los diversos 
programas que estan en un momento dado en ejecucion en la computadora, 
este mecanismo es todavia mas util cuando se usan bibliotecas del sistema: hay 
bibliotecas que son empleadas por una gran cantidad de programas^^. 

Claro esta, para ofrecer este modelo, el sistema operative debe garantizar 
que las paginas correspondientes a las secciones de texto (el codigo del progra- 
ma) sean de solo lectura. 

Un programa que esta desarrollado y compilado de forma que permita que 
todo su codigo sea de solo lectura posibilita que diversos procesos entren a su 
espacio en memoria sin tener que sincronizarse con otros procesos que lo esten 
empleando. 



es que la distribucion resultante en M sea homog^nea y tan poco dependiente de la secuencialidad 
de la entrada como sea posible. 

^^A una lista y no a un valor unico dado que una funcion digestora es necesariamente proclive 
a presentar colisiones; el sistema debe poder resolver dichas colisiones sin perdida de informacion. 

^''Algunos ejemplos sobresalientes podrian ser la libc o glibc, que proporciona las funcinoes 
estandar del lenguaje C y es, por tanto, requerida por casi todos los programas del sistema; los 
diferentes entomos grdficos (en los Unixes modemos, los principales son Qt y Gtk); bibliotecas 
para el manejo de cifrado (openssl), compresibn (zlib), im^genes (libpng, lib jpeg), etcetera. 
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Proceso A 


Pagina 


Marco 






N 


■ 











Proceso B 


Pagina 


Marco 


1 




2 
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Pagina 
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Memoria compartida 



Paginas de 
memoria 



Figura 5.12: Uso de memoria compartida: tres procesos comparter\ la memoria ocu- 
pada por el texto del programa (azul), difieren solo en los datos. 



Copiar al escribir (copy on write, CoW) 

En los sistemas Unix, el mecanismo mas frecuentemente utilizado para 
crear un nuevo proceso es el empleo de la llamada al sistema f ork ( ) . Cuan- 
do es invocado por un proceso, el sistema operativo crea un nuevo proceso 
identico al que lo llamo, diferenciandose linicamente en el valor entregado por la 
llamada a f ork ( ) . Si ocurre algiin error, el sistema entrega un niimero nega- 
tivo (indicando la causa del error). En caso de ser exitoso, el proceso nuevo (o 
proceso hijo) recibe el valor 0, mientras que el preexistente (o proceso padre) 



recibe el PID (numero identificador de proceso) del hijo. Es frecuente encontrar 
el siguiente codigo: 


1 


/* (...) */ 


2 


int pid; 


3 


/* (...) */ 


4 


pid = fork () ; 


5 


if (pid == 0) { 


6 


/* Soy el proceso hijo */ 


7 


/* (...) */ 


8 


} else if (pid < 0) { 


9 


/* Ocurrio un error, no se creo un proceso hijo */ 


10 


} else { 


11 


/ * Soy el proceso padre */ 


12 


/ * La variable 'pid' tiene el PID del proceso hijo */ 


13 


/* (...) */ 


14 


} 







Este metodo es incluso utilizado normalmente para crear nuevos procesos, 
transfiriendo el ambiente (variables, por ejemplo, que incluyen cual es la entrada 
y salida estandar de un proceso, esto es, a que terminal estan conectados, indis- 
pensable en un sistema multiusuario). Frecuentemente, la siguiente instruccion 
que ejecuta un proceso hijo es execve { ) , que carga a un nuevo programa so- 
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bre el actual y transfiere la ejecucion a su primera instruccion. 

Cuesta trabajo comprender el por que de esta logica si no es por el empleo 
de la memoria compartida: el costo de f ork ( ) en un sistema Unbc es muy ba- 
jo, se limita a crear las estructuras necesarias en la memoria del niicleo. Tanto 
el proceso padre como el proceso hijo comparten todas sus paginas de memo- 
ria, como lo ilustra la figiira 5.13(a), sin embargo, siendo dos procesos inde- 
pendientes, no deben poder modificarse mas que por los canales expHcitos de 
comunicacion entre procesos. 

Esto ocurre asl gracias al mecanismo llamado copiar al escribir (frecuente- 
mente referido por sus siglas en ingles, CoW). Las paginas de memoria de am- 
bos procesos son las mismas mientras sean solo leidas. Sin embargo, si uno de los 
procesos modifica cualquier dato en una de estas paginas, esta se copia a un 
nuevo marco, y deja de ser una pagina compartida, como se puede ver en la 
figura 5.13(b). El resto de las paginas seguira siendo compartido. Esto se pue- 
de lograr marcando todas las paginas compartidas como solo lectura, con lo cual 
cuando uxio de los dos procesos intente modificar la informacion de alguna pa- 
gina se generara un fallo. El sistema operativo, al notar que esto ocujtxe sobre 
un espacio CoW, en vez de responder al fallo terminando al proceso, copiara 
solo la pagina en la cual se encuentra la direccion de memoria que causo el 
fallo, y esta vez marcara la pagina como lectura y escritura. 

Incluso cuando se ejecutan nuevos programas mediante execve ( ) , es po- 
sible que una buena parte de la memoria se mantenga compartida, por ejemplo, 
al referirse a copias de bibliotecas de sistema. 

5.7. Memoria virtual 

Varios de los aspectos mencionados en la seccion 5.6 {paginacion) van con- 
formando a lo que se conoce como memoria virtual: en un sistema que emplea 
paginacion, un proceso no conoce su direccion en memoria relativa a otros pro- 
cesos, sino que trabajan con vma idealizacion de la memoria, en la cual ocupan el 
espacio completo de direccionamiento, desde el cero hasta el lunite logico de la 
arquitectura, independientemente del tamano ffsico de la memoria disponible. 

Y si bien en el modelo mencionado de paginacion los diferentes procesos 
pueden compartir regiones de memoria y direccionar mas memoria de la ffsi- 
camente disponible, no se ha presentado aiin la estrategia que se emplearia 
cuando el total de paginas solicitadas por todos los procesos activos en el sis- 
tema superara el total de espacio ffsico. Es ahf donde entra en juego la memoria 
virtual: para ofrecer a los procesos mayor espacio en memoria de con el que se 
cuenta ffsicamente, el sistema emplea espacio en almacenamiento secundario (tf- 
picamente, disco duro), mediante un esquema de intercambio (swap) guardando 
y trayendo paginas enteras. 

Es importante apuntar que la memoria virtual es gestionada de forma au- 
tomdtica y transparente por el sistema operativo. No se hablarfa de memoria 
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Proc. Padre 
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abcdefgh 
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(a) Inmediatamente despues de la creacion del proceso hijo por fork ( ) 



Proc. Padre 


1 
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(b) Cuando el proceso hijo modifica informacion en la primer pagina de su memoria, se 
crea como una pagina nueva. 

Figtira 5,13: Memoria de dos procesos en un sistema que implementa copiar al escri- 
bir. 
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Figura 5.14: Esquema general de la memoria, incorporando espacio en almacena- 
miento secundario, representando la memoria virtual. 



virtual, por ejemplo, si un proceso pide explicitamente intercambiar determi- 
nadas paginas. 

Puesto de otra manera: del mismo modo que la segmentacion (seccion 5.5) 
permitio hacer mucho mas comodo y litil al intercambio (5.4.1) por medio del 
intercambio parcial (5.5.2), permitiendo que continuara la ejecucion del proce- 
so, incluso con ciertos segmentos intercambiados (swappeados) a disco, la memo- 
ria virtual lo hace aiin mas conveniente al aumentar la granularidad del inter- 
cambio: ahora ya no se enviaran a disco secciones logicas completas del proce- 
so (segmentos), sino que se podra reemplazar pagina por pagina, aumentando 
significativamente el rendimiento resultante. Al emplear la memoria virtual, 
de cierto modo la memoria fisica se vuelve solo una proyeccidn parcial de la 
memoria logica, potencialmente mucho mayor a esta. 

Tecnicamente, cuando se habla de memoria virtual, no se esta haciendo 
referencia a un intercambiador {swapper), sino al paginador. 



5.7.1. Paginacion sobre demanda 

La memoria virtual entra en juego desde la carga misma del proceso. Se 
debe considerar que hay una gran cantidad de codigo durmiente o inalcanzable: 
aquel que solo se emplea eventualmente, como el que responde ante ima situa- 
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cion de excepcion o el que se emplea solo ante circunstancias particulares (por 
ejemplo, la exportacion de un documento a determinados formatos, o la veri- 
ficacion de que no haya tareas pendientes antes de cerrar un programa). Y si 
bien a una computadora le seria imposible ejecutar codigo que no este cargado 
en memoria,^'' este si puede comenzar a ejecutarse sin estar completamente en 
memoria: basta con haber cargado la pagina donde estan las instrucciones que 
permiten continuar con su ejecucion actual. 

La paginacion sobre demanda significa que, para comenzar a ejecutar un pro- 
ceso, el sistema operativo carga solamente la porcion necesaria para comenzar la 
ejecucion (posiblemente una pagina o ninguna), y que a lo largo de la ejecu- 
cion, el paginador esflojo-}^ solo carga a memoria las paginas cuando van a ser 
utilizadas. Al emplear un paginador /Zo/o, las paginas que no sean requeridas 
nunca seran siquiera cargadas a memoria. 

La estructura empleada por la MMU para implementar un paginador flojo es 
muy parecida a la descrita al hablar del buffer de traducion adelantada (seccion 
5.6.2): la tabla de paginas rncluira un bit de validez, indicando para cada pagina 
del proceso si esta presente o no en memoria. Si el proceso intenta emplear 
una pagina que este marcada como no valida, esto causa un fallo de pagina, 
que lleva a que el sistema operativo lo suspenda y traiga a memoria la pagina 
solicitada para luego continuar con su ejecucion: 

1. Verifica en el PCB si esta solicitud corresponde a una pagina que ya ha 
sido asignada a este proceso. 

2. En caso de que la referenda sea invalida, se termina el proceso. 

3. Procede a traer la pagina del disco a la memoria. El primer paso es buscar 
un marco disponible (por ejemplo, por medio de una tabla de asignacion 

de marcos). 

4. Solicita al disco la lectura de la pagina en cuestion hacia el marco especi- 
ficado. 

5. Una vez que finaliza la lectura de disco, modifica tanto al PCB como al 
TLB para indicar que la tabla esta en memoria. 

6. Termina la suspension del proceso, continuando con la instruccion que 
desencadeno al fallo. El proceso puede continuar sin notar que la pagina 
habla sido intercambiada. 

Llevando este proceso al extremo, se puede pensar en un sistema de pagi- 
nacion pummente sobre demanda {pure demand paging): en un sistema asl, ninguna 

^^Una computadora basada en la arquitectura von Neumann, como practicamente todas las exis- 
ten hoy en dia, no puede ver directamente mas que la memoria principal. 

i^En computo, muchos procesos pueden determinarse como ansiosos (eager), cuando buscan rea- 
lizar todo el trabajo que puedan desde el inicio, o flops (lazy), si buscan hacer el trabajo minimo en 
im principio y diferir para mds tarde tanto como sea posible. 
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Figura 5.15: Pasos que atraviesa la respuesta a un fallo de pagina. 



pagina Uegara al espacio de un proceso si no es mediante de un fallo de pagina. 
Un proceso, al iniciarse, comienza su ejecucion sin ninguna pagina en memoria, y 
con el apujntador de siguiente instruccion del procesador apuntando a una di- 
reccion que no esta en memoria (la direccion de la rutina de inicio). El sistema 
operativo responde cargando esta primer pagina, y conforme avanza el flujo 
del programa, el proceso ira ocupando el espacio real que empleara. 



5.7.2. Rendimiento 

La paginacion sobre demanda puede impactar fuertemente el rendimiento 
de un proceso -se ha explicado ya que un acceso a disco es varios miles de ve- 
ces mas lento que el acceso a memoria. Es posible calcular el tiempo de acceso 
efectivo a memoria {te) a partir de la probabilidad que en un proceso se presen- 
te un fallo de pagina (0 < p < 1), conociendo el tiempo de acceso a memoria 
(ifl) y el tiempo que toma atender a un fallo de pagina {tf): 
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te = {1- p)ta + ptf 

Ahora bien, dado que ta ronda hoy en dia entre los 10 y 200ns, mientras que 
t f esta mas bien cerca de los 8 ms (la latencia tipica de un disco duro es de 3 ms, 
el tiempo de posicionamiento de cabeza de 5ms, y el tiempo de transferencia 
es de 0.05 ms), para propositos practicos se puede ignorar a ta- Con los valores 
presentados, seleccionando el mayor de los ta presentados, si solo ujn acceso a 
memoria de cada 1000 ocasiona un faUo de pagina (esto es, p — Ymo^'- 

1 1 
= (1 - ^r^) X 200ns + — - x 8 000 000ns 
' ^ 1000^ 1000 

te = 199,8ns + 8 000ns = 8 199,8ns 

Esto es, en promedio, se tiene un tiempo efectivo de acceso a memoria 40 
veces mayor a que si no se empleara este mecanismo. Con estos mismos niime- 
ros, para mantener la degradacion de rendimiento por acceso a memoria por 
debajo de 10%, se deberia reducir la probabilidad de fallos de pagina a 399^990- 

Cabe mencionar que esta repercusion al rendimiento no necesariamente 
significa que una proporcion relativamente alta de fallos de pagina para un 
proceso afecte negativamente a todo el sistema — el mecanismo de paginacion 
sobre demanda permite, al no requerir que se tengan en memoria todas las pa- 
ginas de un proceso, que haya mas procesos activos en el mismo espacio en me- 
moria, aumentando el grado de multiprogramacion del equipo. De este modo, 
si un proceso se ve obligado a esperar por 8 ms a que se resuelva un faUo de 
pagina, durante ese tiempo pueden seguirse ejecutando los demas procesos. 

Acomodo de las paginas en disco 

El calculo recien presentado, ademas, asume que el acomodo de las paginas 
en disco es optimo. Sin embargo, si para llegar a una pagina hay que resolver 
la direccion que ocupa en un sistema de archives (posiblemente navegar una 
estructura de directorio), y si el espacio asignado a la memoria virtual es com- 
partido con los archivos en disco, el rendimiento sufrira adicionalmente. 

Una de las principales deficiencias estructurales en este sentido de los sis- 
temas de la familia Windows es que el espacio de ahnacenamiento se asigna 
en el espacio libre del sistema de archivos. Esto Ueva a que, conforme crece la 
fragmentacion del disco, la memoria virtual quede esparcida por todo el disco 
duro. La generalidad de sistemas tipo Unix, en contraposicion, reservan una 
particion de disco exclusivamente para paginacion. 

5.7.3. Reemplazo de paginas 

Si se aprovechan las caracteristicas de la memoria virtual para aumentar el 
grado de multiprogramacion, como se explico en la seccion anterior, se presen- 
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ta un problema: al sobre-comprometer memoria, en determinado momento, los 
procesos que estan en ejecucion pueden caer en un patron que requiera car- 
garse a memoria flsica paginas por vn mayor uso de memoria que el que hay 
fisicamente disponible. 

Y si se tiene en cuenta que uno de los objetivos del sistema operativo es 
otorgar a los usuarios la ilusidn de ima computadora dedicada a sus procesos, 
no seria aceptable terminar la ejecucion de un proceso ya aceptado y cuyos 
requisites han sido aprobados, porque no hay suficiente memoria. Se vuelve 
necesario encontrar una forma justa y adecuada de Uevar a cabo un reemplazo 
de paginas que permita continuar satisfaciendo sus necesidades. 

El reemplazo de paginas es una parte fundamental de la paginacion, ya 
que es la pieza que posibilita una verdadera separacion entre memoria logica 
y flsica. El mecanismo basico a ejecutar es simple: si todos los marcos estan 
ocupados, el sistema debera encontrar una pagina que pueda liberar (una pd- 
gina victima) y grabarla al espacio de intercambio en el disco. Luego, se puede 
emplear el espacio recien liberado para cargar la pagina requerida, y continuar 
con la ejecucion del proceso. 

Esto implica una dohle transferencia al disco (una para grabar la pagina vic- 
tima y una para traer la pagina de reemplazo), y por tanto, a una doble demora. 

Se puede, con un mlnimo de burocracia adicional (aunque requiere de apoyo 
de la MMU): implementar un mecanismo que disminuya la probabilidad de 
tener que realizar esta doble transferencia: agregar un bit de modificacion o bit 
de pagina sucia {dirty bit) a la tabla de paginas. Este bit se marca como apagado 
siempre que se carga una pagina a memoria, y es automaticamente encendido 
por hardware cuando se realiza un acceso de escritura a dicha pagina. 

Cuando el sistema operativo elige vma pagina victima, si su bit de pagina 
sucia esta encendido, es necesario grabarla al disco, pero si esta apagado, se 
garantiza que la informacion en disco es identica a su copia en memoria, y 
permite ahorrar la mitad del tiempo de transferencia. 

Ahora bien, ^como decidir que paginas reemplazar marcandolas como victi- 
mas cuando hace falta? Para esto se debe implementar un algoritmo de reemplazo 
de paginas. La caracterlstica que se busca en este algoritmo es que, para una 
patron de accesos dado, permita obtener el menor niimero de fallos de pagina. 

De la misma forma como se realize la descripcion de los algoritmos de pla- 
nificacion de procesos, para analizar los algoritmos de reemplazo se usara una 
cadena de referenda, esto es, una lista de referencias a memoria. Estas cadenas 
modelan el comportamiento de un conjunto de procesos en el sistema, y, ob- 
viamente, diferentes comportamientos llevaran a resultados distintos. 

Hacer un volcado y trazado de ejecucion en un sistema real puede dar una 
enorme cantidad de informacion, del orden de im millon de accesos por segun- 
do. Para reducir esta informacion en un niimero mas tratable, se puede simpli- 
ficar basado en que no interesa cada referenda a una direccidn de memoria, sino 
cada referenda a una pagina diferente. 
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Ademas, varios accesos a direcciones de memoria en la misma pagina no 
causan efecto en el estado. Se puede tomar como un solo acceso a todos aque- 
llos que ocurren de forma consecutiva (esto es, sin llamar a ningima otra pagi- 
na, no es necesario que sean en instrucciones consecutivas) a una misma pagi- 
na. 

Para analizar a un algoritmo de reemplazo, si se busca la cantidad de fallos 
de pagina producidos, ademas de la cadena de referenda, es necesario cono- 
cer la cantidad de paginas y marcos del sistema que se esta modelando. For 
ejemplo, considerese la cadena de 12 solicitudes: 

1,4,3,4,1,2,4,2,1,3,1,4 

Al recorrerla en un sistema con cuatro o mas marcos, solo se presentarian 
cuatro fallos (el fallo inicial que hace que se cargue por primera vez cada una 
de las paginas). Si, en el otro extremo, se cuenta con solo un marco, se presenta- 
rian 12 fallos, dado que a cada solicitud se deberia reemplazar el linico marco 
disponible. El rendimiento evaluado seria en los casos de que se cuenta con 
dos o tres marcos. 

Un fenomeno interesante que se presenta con algunos algoritmos es la ano- 
malta de Belady, publicada en 1969: si bien la logica indica que a mayor numero 
de marcos disponibles se tendra una menor cantidad de fallos de pagina, como 
lo ilustra la figura 5.16(a), con algunas de cadenas de referenda y bajo ciertos 
algoritmos puede haber una regresion o degradacion, en la cual la cantidad de 
fallos aumenta aiin con una mayor cantidad de marcos, como se puede ver en 
la figura 5.16(b). 

Es importante recalcar que si bien la anomalla de Belady se presenta como 
un problema importante ante la evaluacion de los algoritmos, en el texto de 
Luis La Red (pp. 559-569) se puede observar que en simulaciones con caracte- 
risticas mas cercanas a las de los patrones reales de los programas, su efecto 
observado es practicamente nulo. 

Para los algoritmos que se presentan a continuacion, se asumira vina me- 
moria con tres marcos, y con la siguiente cadena de referenda: 

7, 0, 1, 2, 0, 3, 0, 4, 2, 3, 0, 3, 2, 1, 2, 0, 1, 7, 0, 1 



Primero en entrar, primero en salir (FIFO) 

El algoritmo de mas simple y de obvia implementacion es, nuevamente, el 
FIFO: al cargar una pagina en memoria, se toma nota de en que momento fue 
cargada, y cuando sea necesario reemplazar una pagina vieja, se elige la que 
haya sido cargada hace mas tiempo. 

Partiendo de un estado inicial en que las tres paginas estan vadas, necesa- 
riamente las tres primeras referencias a distintas paginas de memoria (7, 0, 1) 
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(b) Comportamiento del algoritmo *fifo* exhibiendo la anomalia de 
Belady al pasar de tres a cuatro marcos. 



Figura 5.16: Anomalia de Belady, empleando la cadena de referenda 1, 2, 3, 4, 1, 2, 
5, 1, 2, 3, 4, 5 (Belady, 1969). 



200 



CAPITULOS. ADMINISTRACION DE MEMORIA 



M 
A 
R 
C 
O 
S 



Cadena de referenda 
7 0 12 

III; 



I I I I I 



4 




4 




4 


3 




2 




2 


0 




0 




3 



M 

A 
R 
C 
O 
S 



Cadena de referenda 



I I 



I I I 



0 




0 




0 




0 




0 




0 




0 




7 




7 




7 


2 




2 




2 




1 




1 




1 




1 




1 




0 




0 


3 




3 




3 




3 




2 




2 




2 




2 




2 




1 



Figura 5.17: Algoritmo FIFO de reemplazo de pAginas. 



causaran fallos de pagina. La sigmente (2) causara iino, pero la quinta referen- 
da (0) puede ser satisfecha sin requerir una nueva transferencia. 

La principal ventaja de este algoritmo es, como ya se ha mencionado, la 
simplicidad, tanto para programarlo como para comprenderlo. Su implemen- 
tacion puede ser tan simple como una lista ligada circular, cada elemento que 
va recibiendo se agrega en el ultimo elemento de la lista, y se "empuja" el 
apuntador para convertirlo en la cabeza. Su desventaja, claro esta, es que no 
toma en cuenta la historia de las ultimas solicitudes, por lo que puede causar 
\m bajo rendimiento. Todas las paginas tienen la misma probabilidad de ser 
reemplazadas, sin importar su frecuencia de uso. 

Con las condiciones aqm presentadas, un esquema FIFO causara 15 fallos 
de pagina en un total de 20 accesos requeridos. 

El algoritmo FIFO es vulnerable a la anomalla de Belady. La figura 5.16(b) 
ilustra este fenomeno al pasar de tres a cuatro marcos. 

La prevalencia de cadenas que desencadenan la anomalfa de Belady fue 
uno de los factores principales que Uevaron al diseno de nuevos algoritmos de 
reemplazo de paginas. 



Reemplazo de paginas optimo (OPT, MIN) 

Un segundo algoritmo, de interes puramente teorico, fue propuesto, y es 
tlpicamente conocido como opt o MIN. Bajo este algoritmo, el enuxiciado sera 
elegir como pagina vfctima a aqueUa pagina que no vaya a ser utilizada por un 
tiempo maximo (o nimca mas). 
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Figura 5.18: Algoritmo optimo de reemplazo de paginas (OPT). 



Si bien este algoritmo esta demostrado como optimo o mmimo, se mantiene 
como curiosidad teorica porque requiere conocimiento a priori de las necesida- 
des a future del sistema — y si esto es impracticable ya en los algoritmos de 
despachadores, lo sera mucho mas con un recurso de reemplazo tan dinamico 
como la memoria. 

Su principal utilidad reside en que ofrece una cota minima: calculando el 
niimero de fallos que se presentan al seguir OPT, es posible ver que tan cercano 
resulta otro algoritmo respecto al caso optimo. Para esta cadena de referenda, 
y con tres paginas, se tiene \m total de nueve fallos. 



Menos recientemente utilizado (LRU) 

Este esquema se ha revisado en diversos mecanismos relacionados con la 
administracion de memoria. Busca acercarse a OPT prediciendo cuando sera la 
proxima vez en que se emplee cada una de las paginas que tiene en memoria 
basado en la historia reciente de su ejecucion. 

Cuando necesita elegir una pagina vlctima, LRU elige la pagina que no ha 
sido empleada hace mas tiempo. 

Para la cadena de referenda, LRU genera 12 fallos, en el punto medio entre 

OPT y FIFO. 

Una observacion interesante puede ser que para una cadena S y su cadena 
espejo (invertida) R^, el resviltado de evaluar S empleando LRU es igual al de 
evaluar con OPT, y viceversa. 

La principal debilidad de LRU es que para su implementacion reqmere apo- 
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Figura 5.19: Algoritmo reemplazo de paginas menos recientemente utilizadas 
(LRU). 



yo en hardware^^ sensiblemente mas complejo que FIFO. Una implementacion 
podria ser agregar un contador a cada uno de los marcos, actualizarlo siempre 
al hacer iina referenciar a dicha pagina, y elegir como victima a la pagina con 
\m menor conteo. Este mecanismo tiene la desventaja de que, en presencia de 
una gran cantidad de paginas, tiene que recorrerlas todas para buscar la mas 
envejecida. 

Otro mecanismo es emplear una lista doblemente ligada con dos metodos 
de acceso: lista y stack. Cada vez que se haga referencia a una pagina, esta se 
mueve a la cabeza del stack, y cada vez que se busque una pagina vfctima, se 
selecciona a aquella que este en el extremo inferior del stack (tomandolo como 
lista). Este mecanismo hace un poco mas cara la actualizacion (pueden reque- 
rirse hasta seis modificaciones), pero encuentra la pagina victima en tiempo 
constante. 

Se ha demostrado que LRU y oft estan libres de la anomalla de Belady, 
dado que, para n marcos, las paginas que estarfan en memoria son \m subcon- 
junto estricto de las que estarian con n + 1 marcos. 



Mas frecuentemente utilizada (MFU)/Menos frecuentemente utilizada (LFU) 

Estos dos algoritmos se basan en mantener un contador, tal como lo hace 
LRU, pero en vez de medir el tiempo, miden la cantidad de referencias que se 

^'Dada la frecuencia con que se efecttian referencias a memoria, emplear un mecanismo pura- 
mente en software para actualizar las entradas de los marcos resultarla inaceptablemente lento. 
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han hecho a cada pagina. 

El MFU parte de la logica que, si una pagina fue empleada muchas veces, 
probablemente vuelva a ser empleada muchas veces mas; LFU parte de que vma 
pagina que ha sido empleada pocas veces es probablemente \ma pagina recien 
cargada, y va a ser empleada en el future cercano. 

Estos dos algoritmos son tan caros de implementar como LRU, y su rendi- 
miento respecto a OPT no es tan cercana, por lo cual casi no son empleados. 

Aproximaciones a LRU 

Dada la complejidad que presenta la implementacion de LRU en hardware, 
los siguientes sistemas buscan una aproximacion a este. 

Bit de referencia Esta es una aproximacion bastante comun. Consiste en que 
todas las entradas de la tabla de paginas tengan un bit adicional, al que 
llamaremos de referencia o de acceso. Al iniciar la ejecucion, todos los bits 
de referencia estan apagados (0). Cada vez que se referencia a un marco, 
su bit de referencia se enciende (esto, en general, lo realiza el hardware). 

El sistema operative invoca periodicamente a que se apaguen nuevamen- 
te todos los bits de referencia. En caso de presentarse un fallo de pagina, 
se elige por FIFO sobre el subconjunto de marcos que no hayan sido re- 
ferenciados en el periodo actual (esto es, entre todos aqueUos para los 
cuales el bit de referencia sea 0). 

Columna de referencia Una mejorfa casi trivial sobre la anterior consiste en 
agregar varios bits de referencia, conformandose como una columna: en 
vez de descartar su valor cada vez que transcurre el periodo determi- 
nado, el valor de la columna de referencia es desplazado a la derecha, 
descartando el bit mas bajo (una actualizacion solo modifica el bit mas 
significative). Por ejemplo, con una implementacion de cuatro bits, \m 
marco que no ha sido empleado en los ultimos cuatro periodos tendrfa 
el valor 0 000, mientras que un marco que si ha sido referenciado los ul- 
timos cuatro periodos tendria 1 111. Un marco que fue empleado hace 
cuatro y tres periodos, pero a partir entonces ya no, tendria el 0011. 

Cuando el sistema tenga que elegir a una nueva pagina vktima, lo hara 
de entre el conjunto que tenga un numero mas bajo. 

La parte de mantenimiento de este algoritmo es muy simple; recorrer 
una serie de bits es una operacion muy sencilla. Seleccionar el numero 
mas bajo requiere ima pequena biisqueda, pero sigue resiiltando mucho 
mas sencillo que LRU. 

Segunda oportunidad (o reloj) El algoritmo de la segimda oportunidad tra- 
baja tambien basado en xa\ bit de referencia y un recorrido tipo FIFO. La 



204 



CAPITULOS. ADMSSHSTRACION DE MEMORIA 



diferencia en este caso es que, al igual que hay eventos que encienden a 
este bit (efectuar una referencia al marco), hay otros que lo apagan: 

se mantiene un apuntador a la proxima vtctima, y cuando el sistema re- 
quiera efectuar un reemplazo, este verificara si el marco al que apiinta 
tiene el bit de referencia encendido o apagado. En caso de estar apagado, 
el marco es seleccionado como victima, pero en caso de estar encendido 
(indicando que fue utilizado recientemente), se le da ima segunda opor- 
tunidad: el bit de referencia se apaga, el apuntador de victima potencial 
avanza una posicion, y vuelve a intentarlo. 

A este algoritmo se le llama tambien de reloj porque puede unplementarse 
como tma lista ligada circular, y el apuntador puede ser visto como una 
manecilla. La manecilla avariza sobre la lista de marcos buscando uno 

con el bit de referencia apagado, y apagando a todos a su paso. 

En el peor caso, el algoritmo de segunda oportunidad degenera en FIFO. 

Segunda oportunidad mejorada El bit de referencia puede ampliarse con un 
bit de modificacion, dandonos las siguientes combinaciones, en orden de 
preferencia: 

(0, 0) No ha sido utilizado ni modificado recientemente. Candidato ideal 
para su reemplazo. 

(0,1) No ha sido utilizada recientemente, pero esta modificada. No es tan 
buena opcion, porque es necesario escribir la pagina a disco antes 
de reemplazarla, pero puede ser elegida. 

(1.0) El marco esta limpio, pero fue empleado recientemente, por lo que 
probablemente se vuelva a requerir pronto. 

(1.1) Empleada recientemente y sucia — seria necesario escribir la pagina 
a disco antes de reemplazar, y probablemente vuelva a ser requerida 
pronto. Hay que evitar reemplazarla. 

La logica para encontrar una pagina victuna es similar a la segunda opor- 
tunidad, pero busca reducir el costo de E/S. Esto puede requerir, sin em- 
bargo, dar hasta cuatro vueltas (por cada una de las listas) para elegir la 
pagina victima. 

Algoritmos con manejo de buffers 

Un mecanismo que se emplea cada vez con mayor frecuencia es que el sis- 
tema no espere a enfrentarse a la necesidad de reemplazar un marco, sino que 
proactivamente busque tener siempre espacio vacio en memoria. Para hacerlo, 
conforme la carga lo permite, el sistema operativo busca las paginas sucias mas 
proclives a ser paginadas a disco y va actualizando el disco (y marcandolas 
nuevamente como limpias). De este modo, cuando tenga que traer una pagina 
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nueva del disco, siempre habra espacio donde ubicarla sin tener que esperar a 
que se transfiera una para liberarla. 

5.7.4. Asignacion de marcos 

Abordando el problema practicamente por el lado opuesto al del reemplazo 
de paginas, ^como se asignan los marcos existentes a los procesos del sistema? 
Esto es, ^que esquemas se pueden definir para que la asignacion inicial (y, de 
ser posible, en el transcurso de la ejecucion) sea adecuada? 

Por ejemplo, usando esquema sendllo: un sistema con 1 024 KB de memoria, 
compuesta de 256 paginas de 4096 bytes cada una, y basado en paginacion 
puramente sobre demanda. 

Si el sistema operativo ocupa 248 KB, el primer paso sera reservar las 62 
paginas que este requiere, y destinar las 194 paginas restantes para los procesos 
a ejecutar. 

Conforme se van lanzando y comienzan a ejecutar los procesos, cada vez 
que uno de ellos genere tin fallo de pagina, se le ira asignando uno de los mar- 
cos disponibles hasta causar que la memoria entera este ocupada. Claro esta, 
cuando un proceso termine su ejecucion, todos los marcos que tenia asignados 
volveran a la lista de marcos libres. 

Una vez que la memoria este completamente ocupada (esto es, que haya 
194 paginas ocupadas por procesos), el siguiente fallo de pagina invocara a un 
algoritmo de reemplazo de pagina, que elegira una de las 194.^" 

Este esquema, si bien es simple, al requerir una gran cantidad de fallos 
de pagina expHcitos puede penalizar el rendimiento del sistema — el esque- 
ma puede resultar demasiado flop, no le vendrla mal ser un poco mas ansioso y 
asignar, de inicio, im mimero determinado como mlnimo utilizable de marcos. 

Minimo de marcos 

Si un proceso tiene asignados muy pocos marcos, su rendimiento induda- 
blemente se vera afectado. Hasta ahora se ha supuesto que cada instruccion 
puede causar un solo fallo de pagina, pero la realidad es mas compleja. Cada 
instruccion del procesador puede, dependiendo de la arquitectura, desencade- 
nar varias solicitudes y potenciaLmente varios fallos de pagina. 

Todas las arquitecturas proporcionan instrucciones de referenda directa a 
memoria (instrucciones que permiten especificar una direccion de memoria pa- 
ra leer o escribir) — esto significa que todas requeriran que, para que un pro- 
ceso funcione adecuadamente, tenga por lo menos dos marcos asignados: en 
caso de que se le permitiera solo uno, si la instruccion ubicada en 0x00A2C8 

^"En realidad, dentro de la memoria del sistema operativo, al igual que la de cualquier otro 
proceso, hay regiones que deben mantenerse residentes y otras que pueden paginarse. Se puede, 
simpUflcando, omitir por ahora esa complicaci6n y asiimir que el sistema operativo completo se 
mantendr^ siempre en memoria 
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solicita la carga de 0x043F00, esta causaria dos fallos: el primero, cargar al 
marco la pagina 0 x 0 4 3 , y el segundo, cargar nuevamente la pagina 0 x 0 0 A, ne- 
cesario para leer la sigmente instruccion a ejecutar del programa (0x00A2CC, 
asumiendo palabras de 32 bits). 

Algimas arquitecturas, ademas, permiten referencias indirectas a memoria, es- 
to es, la direccion de carga puede solicitar la direccion que estd referenciada en 
0x043F00. El procesador tendria que recuperar esta direccion, y podrfa en- 
contrarse con que hace referenda a una direccion en otra pagina (por ejemplo, 
OxOlOFSO). Cada nivel de indireccion que se permite aumenta en uno el nu- 
mero de paginas que se deben reservar como mmimo por proceso. 

Algunas arquitecturas, particularmente las mas antiguas,-^^ permiten que 
tanto los operandos de algunas instrucciones aritmeticas como su resultado 
sean direcciones de memoria (y no operan estrictamente sobre los registros, 
como las arquitecturas RISC). En estas, el mmimo debe tambien tener este fac- 
tor en cuenta: si en ujna sola instruccion es posible sumar dos direcciones de 
memoria y guardar el resultado en una adicional, el mmimo a reservar es de 
cuatro marcos: \mo para el flujo del programa, otro para el primer operando, 
\mo para el segundo operando, y el ultimo para el resiiltado. 

Esquemas de asignacion 

Ahora, una vez establecido el niimero mlnimo de marcos por proceso, ^co- 
mo determinar el nivel deseable? 

Partiendo de que el rendimiento de im proceso sera mejor entre menos fa- 
llos de paginacion cause, se podrfa intentar otorgar a cada proceso el total de 
marcos que solicita, pero esto tendrfa como resultado disminuir el grado de 
multiprogramacion y, por tanto, reducir el uso efectivo total del procesador. 

Otra altemativa es la asignacion igualitaria: se divide el total de espacio en 
memoria ffsica entre todos los procesos en ejecucion, en partes iguales. Esto es, 
volviendo a la computadora hipotetica que se presento al inicio de esta seccion, 
si hay cuatro procesos que requieren ser ejecutados, de los 194 marcos dispo- 
nibles, el sistema asignara 48 (192 KB) a dos de los procesos y 49 (196 kb) a los 
otros dos (es imposible asignar fracciones de marcos). De este modo, el espacio 
sera compartido por igual. 

La asignacion igualitaria resulta ser un esquema deficiente para casi todas 
las distribuciones de procesos: bajo este esquema, si Pi es un gestor de bases de 
datos que puede estar empleando 2 048 KB (512 paginas) de memoria virtual (a 
pesar de que el sistema tiene solo 1 MB de memoria ffsica) y P2 es un lector de 
texto que esta empleando un usuario, requiriendo apenas 112 KB (28 paginas), 
con lo cual incluso dejarfa algunos de sus marcos sin utilizar. 

Un segundo esquema, que resuelve mejor esta situacion, es la asignacion 



^ Aquellas disenadas antes de que la velocidad del procesador se distanciara tanto del tiempo 
de acceso a memoria. 
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proporcional: dar a cada proceso una porcion del espacio de memoria fisica pro- 
porcional a su uso de memoria virtual. 

De tal suerte que, si ademas de los procesos anteriores se tiene a P3 em- 
pleando 560 KB (140 paginas) y a P4 con 320 KB (80 paginas) de memoria vir- 
tual, el uso total de memoria virtual seria de Vj = 512 + 28 + 140 + 80 = 760 
paginas, esto es, el sistema tendria comprometido mediante la memoria virtual 
un sobreuso cercano a 4:1 sobre la memoria ffsica.^^ 

Cada proceso recibira entonces Fp = ^ x m, donde Fp indica el espacio de 
memoria fisica que el proceso recibira, Vp la cantidad de memoria virtual que 
esta empleando, y m la cantidad total de marcos de memoria disponibles. De 
este modo. Pi recibira 130 marcos, P2 7, P3 35 y P4 20, proporcionalmente a su 
uso de memoria virtual. 

Cabe apuntar que este mecanismo debe observar ciertos parametros mmi- 
mos: por un lado, si el mfnimo de marcos definido para esta arquitectura es de 
cuatro, por mas que entrara en ejecucion un proceso de 32 KB (ocho paginas) 
o aumentara al doble el grado de multiprocesamiento, ningun proceso debe 
tener asignado menos del mmimo definido. 

La asignacion proporcional tambien debe cuidar no sobre-asignar recursos 
a un proceso obeso: Pi es ya mucho mas grande que todos los procesos del sis- 
tema. En caso de que esta creciera mucho mas, por ejemplo, si multiplicara por 
cuatro su uso de memoria virtual, esto llevarfa a que se castigara desproporcio- 
nadamente a todos los demas procesos del sistema. 

Por otro lado, este esquema ignora por completo las prioridades que hoy 
en dfa manejan todos los sistemas operativos; si se quisiera considerar, podria 
incluirse como factor la prioridad, multiplicando junto con Vp. 

El esquema de asignacion proporcional sufre, sin embargo, cuando cambia 
el nivel de multiprogramacion, esto es, cuando se inicia tm nuevo proceso o 
finaliza un proceso en ejecucion, deben recalcularse los espacios en memoria 
fisica asignados a cada uno de los procesos restantes. Si finaliza un proceso, el 
problema es menor, pues solo se asignan los marcos y puede esperarse a que 
se vayan poblando por paginacion sobre demanda, pero si indcia uno nuevo, 
es necesario reducir de golpe la asignacion de todos los demas procesos hasta 
abrir suficiente espacio para que quepa. 

Por ultimo, el esquema de la asignacion proporcional tambien tiende a des- 
perdiciar recursos: si bien hay procesos que mantienen un patron estable de 
actividad a lo largo de su ejecucion, muchos otros pueden tener periodos de 
mucho menor requisites. Por ejemplo, un proceso servidor de documentos pa- 
sa la mayor parte de su tiempo simplemente esperando solicitudes, y podria 
reducirse a un uso minimo de memoria fisica, sin embargo, al solicitarsele un 
documento, se le deberian poder asignar mas marcos (para trabajar en una rd- 
faga) hasta que termine con su tarea. En la seccion 5.7.5 se retomara este tema. 



^Ya que de los 1 024 KB, o 256 pdginas, que tiene el sistema descrito, descontando los 248 KB, o 
62 paginas, que ocupa el sistema operativo, quedan 194 paginas disponibles para los procesos. 
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Ambitos del algoritmo de reemplazo de paginas 

Para atender los problemas no resueltos que se describieron en la seccion 
anterior, se puede discutir el ambito en que operara el algoritmo de reemplazo 
de paginas. 

Reemplazo local Mantener tan estable como sea posible el calculo hecho por 
el esquema de asignacion empleado. Esto significa que cuando se pre- 
sente un fallo de pagina, las linicas paginas que se consideraran para su 
intercambio seran aquellas pertenecientes al mismo proceso que el que cau- 
se el fallo. 

Un proceso tiene asignado su espacio de memoria fisica, y se mantendra 
estable mientras el sistema operative no tome alguxia decision por cam- 
biarlo. 

Reemplazo global Los algoritmos de asignacion determinan el espacio asig- 
nado a los procesos al ser inicializados, e influyen a los algoritmos de 
reemplazo (por ejemplo, dando mayor peso para ser elegidas como pa- 
ginas victima a aquellas que pertenezcan a un proceso que excede de su 
asignacion en memoria fisica). 

Los algoritmos de reemplazo de paginas operan sobre el espacio comple- 
te de memoria, y la asignacion fisica de cada proceso puede variar segtin 
el estado del sistema momento a momento. 

Reemplazo global con prioridad Es un esquema mixto, en el que un proceso 
puede sobrepasar su llmite siempre que le robe espacio en memoria fisica 
exclusivamente a procesos de prioridad inferior a el. Esto es consisten- 
te con el comportamiento de los algoritmos planificadores, que siempre 
dan preferencia a \m proceso de mayor prioridad por sobre de \mo de 
prioridad mas baja. 

El reemplazo local es mas rfgido y no permite aprovechar para mejorar el 
rendimiento los periodos de inactividad de algunos de los procesos. En con- 
traposicion, los esquemas basados en reemplazo global pueden llevar a rendi- 
miento inconsistente: dado que la asignacion de memoria fisica sale del control 
de cada proceso puede que la misma seccion de codigo presente tiempos de 
ejecucion muy distintos si porciones importantes de su memoria fueron pagi- 
nadas a disco. 

5.7.5. Hiperpaginacion 

Es un fenomeno que se puede presentar por varias razones: cuando (bajo 
un esquema de reemplazo local) un proceso tiene asignadas pocas paginas pa- 
ra llevar a cabo su trabajo, y genera faUos de pagina con tal frecuencia que le 
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imposibilita realizar trabajo real. Bajo un esquema de reemplazo global, cuan- 
do hay demasiados procesos en ejecucion en el sistema y los constantes fallos 
y reemplazos hacen imposible a todos los procesos involucrados avanzar, tam- 
bien se presenta hiperpaginacion.-^'' 

Hay varios escenarios que pueden desencadenar la hiperpaginacion, y 
su efecto es tan claro e identificable que practicamente cualquier usuario de 
computo lo sabra reconocer. A continuacion se presentara un escenario ejem- 
plo en que las malas decisiones del sistema operativo pueden conducirlo a este 
estado. 

Suponga un sistema que esta con una carga media normal, con un esquema 
de reemplazo global de marcos. Se lanza un nuevo proceso, que como parte de 
su inicializacion requiere poblar diversas estructuras a lo largo de su espacio 
de memoria virtual. Para hacerlo, lanza una serie de fallos de pagina, a las que 
el sistema operativo responde reemplazando a varios marcos pertenecientes a 
otros procesos. 

Casualmente, a lo largo del periodo que toma esta inicializacion (que puede 
parecer una eternidad: el disco es entre miles y millones de veces mas lento que 
la memoria) algunos de estos procesos solicitan los espacios de memoria que 
acaban de ser enviados a disco, por lo cual lanzan nuevos fallos de pagina. 

Cuando el sistema operativo detecta que la utilizacion del procesador de- 
crece, puede aprovechar la situacion para lanzar procesos de mantenimiento. 
Se lanzan estos procesos, reduciendo aiin mas el espacio de memoria flsica dis- 
ponible para cada uno de los procesos preexistentes. 

Se ha formado ya toda una cola de solicitudes de paginacion, algunas veces 
contradictorias. El procesador tiene que comenzar a ejecutar NOOP (esto es, no 
tiene trabajo que ejecutar), porque la mayor parte del tiempo lo pasa en espera 
de un nuevo marco por parte del disco duro. El sistema completo avanza cada 
vez mas lento. 



Hiperpaginacion 




Grado de multiprogramacion 



Figura 5.20: Al aumentar demasiado el grado de multiprogramacion, el uso del 
CPU cae abruptamente, entrando en hiperpaginacion (Silberschatz, p. 349). 



^^Una traduccion Kteral del termino thrashing, empleado en ingles para designar a este feno- 
meno, resulta mas grafica: paliza. 
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Los smtomas de la hiperpaginacion son muy claros, y no son dificiles de 
detectar. ^Que estrategia puede emplear el sistema operativo una vez que se 
da cuenta que se presento esta situacion? 

Una salida seria reducir el nivel de multiprogramacion — si la paginacion 
se presento debido a que los requisitos de memoria de los procesos actualmen- 
te en ejecucion no pueden ser satisfechos con la memoria fisica disponible, el 
sistema puede seleccionar uno (o mas) de los procesos y suspenderlos por com- 
pleto hasta que el sistema vuelva a un estado normal. Podrla seleccionarse, por 
ejemplo, al proceso con menor prioridad, al que este causando mas cantidad 
de fallos, o al que este ocupando mas memoria. 

Modelando el conjunto activo 

Un pico en la cantidad de fallos de pagina no necesariamente significa que 
se va a presentar una situacion de hiperpaginacion — muchas veces rndica que 
el proceso cambio su atencion de un conjunto de paginas a otro, o dicho de 
otro modo, que cambio elxs conjunto activo del proceso, y resulta natural que, 
al cambiar el conjunto activo, el proceso accese de golpe una serie de paginas 
que no habla referenciado en cierto tiempo. 

nj 
c 

Dl 

^nj 

Q. 

-a 

t/) 
o 

^ 

01 
"D 

nj 
ui 

0 2 4 6 8 10 

Tiempo 

Figura 5.21: Los picos y valles en la cantidad de fallos de pagina de un proceso 
definen su conjunto activo. 

El conjunto activo es, pues, la aproximacion mas clara a la localidad de referen- 
da de un proceso dado: el conjunto de paginas sobre los que esta iterando en 
un momento dado. 

Idealmente, para evitar los problemas relacionados con la hiperpaginacion, 
el sistema debe asignar a cada proceso suficientes paginas como para que man- 
tenga en memoria fisica su conjunto activo — y si no es posible hacerlo, el pro- 
ceso es un buen candidato para ser suspendido. Sin embargo, detectar con sufi- 
ciente claridad como para efectuar este diagnostico cudl es el conjunto activo es 
una tarea muy compleja, que tipicamente implica rastrear y verificar del orden 
de los ultimos miles a decenas de miles de accesos a memoria. 
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5.8. Consideraciones de seguridad 

Para una cobertura a mayor profundidad del material presentado en esta 
seccion, se sugiere estudiar los siguientes textos: 

■ Smashing The Stack For Fun And Profit (Aleph One, revista Phrack, 1996). 

■ The Tao of Buffer Overflows (Enrique Sanchez, inedito, pero disponible 
en Web). 

5.8.1. Desbordamientos de buffer (buffer overflows) 

Una de las funciones principales de los sistemas operativos en la que se ha 
insistido a lo largo del libro es la de implementar proteccion entre los proce- 
sos pertenecientes a diferentes usuarios, o ejecutandose con distinto nivel de 
privilegios. Y si bien el enfoque general que se ha propuesto es el de analizar 
por separado subsistema por subsistema, al hablar de administracion de me- 
moria es necesario mencionar tambien las implicaciones de seguridad que del 
presente tema se pueden desprender. 

En las computadoras de arquitectura von Neumann, todo dato a ser proce- 
sado (sean instrucciones o datos) debe pasar por la memoria, por el almacena- 
miento primario. Solo desde ahf puede el procesador leer la informacion direc- 
tamente. 

A lo largo del presente capitulo se ha mencionado que la MMU incluye ya 
desde el hardware el concepto de permisos, separando claramente las regiones 
de memoria donde se ubica el codigo del programa (y son, por tanto, ejecuta- 
bles y de solo lectura) de aquellas donde se encuentran los datos (de lectura y 
escritura). Esto, sin embargo, no los pone a salvo de los desbordamientos de bujfer 
(buffer overflows), errores de programacion (tlpicamente, la falta de verificacion 
de Hmites) que pueden convertirse en viilnerabilidades.^'* 

La pila de llamadas (stack) 

Recordando lo mencionado en la seccion 5.3.2, en que se presento el espacio 
en memoria de un proceso, es conveniente profundizar un poco mas acerca de 
como esta estructurada la pila de llamadas (stack). 

El stack es el mecanismo que brinda un sentido local a la representacion del 
codigo estructurado. Esta dividido en marcos de activacion (sin relacion con el 
concepto de marcos empleado al hablar de memoria virtual); durante el perio- 
do en que es el marco activo (esto es, cuando no se ha transferido el control a 
ninguna otra funcion), esta delimitado por dos valores, aLmacenados en regis- 
tros: 

^*Citando a Theo de Raadt, autor principal del sistema operativo OpenBSD, todo error es ima 
vulnerabiUdad esperando a ser descubierta. 
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Apuntador a la pila {Stack pointer, SP) Apunta al final actual (direccion inferior) 
de la pila. En arquitecturas x86, emplea el registro ESP; cuando se pide al 
procesador que actiie sobre el stack (con las operaciones pushl o popl), 
lo hace sobre este registro 

Apuntador del marco {Frame pointer, FP, o Base local, LB) Apunta al inicio del 
marco actual, o lo que es lo mismo, al final del marco anterior. En arqui- 
tecturas x86, emplea el registro EBP. 

A cada funcion a la cual va entrando la ejecucion del proceso, se va creando 
im marco de activacion en el stack, que rncluye: 

■ Los argumentos recibidos por la funcion. 

■ La direccion de retomo al codigo que la invoco. 

■ Las variables locales creadas en la funcion. 

Con esto en mente, es posible analizar la traduccion de una llamada a fun- 
cion en C a su equivalente en ensamblador, y en segundo termino ver el marco 
del stack resultante: 

1 void func(int a, int b, int c) { 

2 char buf ferl [5] ; 

3 char buff er2 [10] ; 

4 } 

5 

6 void main ( ) { 

7 func (1,2,3); 

5 } 

Y lo que el codigo resultante en ensamblador efectua es: 

1. El procesador empuja (pushl) los tres argumentos al stack (ESP). La nota- 
cion empleada ($1, $2, $3) indica que el numero indicado se expresa de 
forma literal. Cada uno de estos tres valores restara 4 bytes (el tamano de 
un valor entero en x86-32) a ESP. 

2. En ensamblador, los nombres asignados a las variables y funciones no 
significan nada. La llamada call no es lo que se entenderla como una 
llamada a funcion en un lenguaje de alto nivel — lo que hace el procesa- 
dor es empujar al stack la direccion de la siguiente instruccion, y cargar a 
este la direccion en el fuente donde esta la etiqueta de la funcion (esto es, 
transferir la ejecucion hacia alia). 

3. Lo primero que hace la funcion al ser invocada es asegurarse de saber 
a donde volver: empuja al stack el viejo apuntador al marco (EBP), y lo 
reemplaza (movl) por el actual. A esta ubicacion se le llama SEP {Saved 
Frame Pointer, apuntador al marco grabado) 
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4. For ultimo, con subl, resta el espacio necesario para alojar las variables 
locales, buf ferl y buf fer2. Notaran que, si bien estas son de 5 y 10 
bytes, esta recorriendo 20 bytes — esto porque, en la arquitectura x86-32, 
los accesos a memoria deben estar alineados a 32 bits. 



1 ; main 




2 


pushl $3 


3 


pushl $2 


4 


pushl $1 


5 


call func 


6 




7 f unc : 




8 


pushl %ebp 


9 


movl %esp, %ebp 


10 


subl $20,%esp 



La figura 5.22 ilustra como queda la region inferior del stack (el espacio de 
trabajo de la funcion actual) una vez que tuvieron lugar estos cuatro pasos. 



0x00000000 4 ► OxFFFFFFFF 



buffef2 


bufferl 


sfp 


ret 


a 


b 


c 



12 bytes 8 bytes 4b 4b 4b 4b 4b 



Figura 5.22: Marco del stadc con Uamada a func (1,2,3) en x86-32. 



C y las funciones de manejo de cadenas 

El lenguaje de programacion C fue creado con el proposito de ser tan sim- 
ple como sea posible, manteniendose tan cerca del hardware como se pudiera, 
para que pudiera ser empleado como un lenguaje de programacion para un 
sistema operativo portable. Y si bien en 1970 era visto como un lenguaje rela- 
tivamente de alto nivel, hoy en dia puede ubicarse como el mas bajo nivel en 
que programa la mayor parte de los desarrolladores del mundo. 

C no tiene soporte nativo para cadenas de caracteres. El soporte es provisto 
mediante/flffif/MS de funciones en la biblioteca estandar del lenguaje, que estan 
siempre disponibles en cualquier implementacion estandar de C. Las familias 
prrncipales son strcat, strcpy, printf y gets. Estas funciones trabajan 
con cadenas que siguen la siguiente estructura: 

■ Son arreglos de 1 o mas caracteres (char, 8 bits). 

■ Deben terminar con el byte de terminacion NUL ( \ 0). 
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El problema con estas funciones es que solo algunas de las funciones deri- 
vadas implementan verificaciones de limites, y algunas son incluso capaces de 
crear cadenas ilegales (que no concluyan con el terminador \ 0). 

El problema aparece cuando el programador no tiene el cuidado necesario 
al trabajar con datos de los cuales no tiene certeza. Esto se demuestra con el 
siguiente codigo vulnerable: 

1 #include <stdio.h> 

2 int main(int argc, char **argv) { 

3 char buffer [256]; 

4 if (argc > 1) strcpy (buf f er , argv[l]); 

5 printf ( "Escribiste %s\n", buffer); 

6 return 0 ; 

7 } 

El problema con este codigo reside en el strcpy (buffer, argv[l] ) 
— dado que el codigo es recibido del usuario, no se tiene la certeza de que el ar- 
gumento que recibe el programa por llnea de comandos (empleando argv [ 1 ] ) 
quepa en el arreglo buffer [256]. Esto es, si se ejecuta el programa ejemplo 
con una cadena de 120 caracteres: 

1 $ ./ejemplol 'perl -e 'print "A" x 120'' 

2 Escribiste: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

3 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

4 AAAAAAAAAAAA 

5 $ 

La ejecucion resulta exitosa. Sin embargo, si se ejecuta el programa con un 
parametro demasiado largo para el arreglo: 

1 $ ./ejemplol 'perl -e 'print "A" x 500'' 

2 Escribiste: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

3 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

4 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

5 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

6 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

7 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

8 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

9 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

10 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

11 Segmentation fault 

12 $ 



De una falla a un ataque 

En el ejemplo recien presentado, pareceria que el sistema atrapo al error 
exitosamente y detuvo la ejecucion, pero no lo hizo: el Segmentation fault 
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no fue generado al sobreescribir el buffer ni al intentar procesarlo, sino despues 
de terminar de hacerlo: al Uegar la ejecucion del codigo al return 0. En este 
piinto, el stack del codigo ejemplo luce como lo presenta la figiira 5.23. 



0x00000000 4- 



-> OXFFFFFFFF 



argc, ai gv 



sfp 



ret 



buffer 



4b 4b 256 bytes 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 



Figura 5.23: Estado de la memoria despues del strcpy ( ) . 

Para volver de una funcion a quien la invoco, incluso si dicha funcion es 
main ( ) , lo que hace return es restaurar el viejo SFP y hacer que el apuntador 
a sigmente direccion sake a la direccion que tiene en RET. Sin embargo, como 
se observa en el esquema, ret fue sobreescrito por la direccion 0x41414141 
(AAAA). Dado que esa direccion no forma parte del espacio del proceso actual, 
se lanza una excepcion por violacion de segmento, y el proceso es terminado. 

Ahora, lo expuesto anteriormente implica que el codigo es demostrado vul- 
nerable, pero se ha explotado aiin. El siguiente paso es, conociendo el acomodo 
exacto de la memoria, sobreescribir unicamente lo necesario para alterar el flu- 
jo del programa, esto es, sobreescribir RET con una direccion valida. Para esto, 
es necesario conocer la longitud desde el inicio del buffer hasta donde termi- 
nan RET y SFP, en este caso particular, 264 bytes (256 del buffer mas cuatro de 
RET mas cuatro de SFP). 

Citando al texto de Enrique Sanchez, 

iPor que ociirre un desbordamiento de stack? Imagina un vaso y 
una botella de cerveza. ^Que ocurre si sirves la botella completa 
en el vaso? Se va a derramar. Imagina que tu variable es el vaso, 
y la entrada del usuario es la cerveza. Puede ocurrir que el usuario 
sirva tanto Ifquido como el que cabe en el vaso, pero puede tambien 
seguir sirviendo hasta que se derrame. La cerveza se derramaria en 
todas direcciones, pero la memoria no crece de esa manera, es solo 
un arreglo bidimensional, y solo crece en una direccion. 

Ahora, ^que mas pasa cuando desbordas un contenedor? El Ifquido 
sobrante va a mojar la botana, los papeles, la mesa, etc. En el caso 
de los papeles, destruira cualquier cosa que hubieras apuntado (co- 
mo el telefono que acabas de anotar de esa linda chica). Cuando tu 
variable se desborde, ique va a sobrescribir? Al EBP, al EIP, y lo 
que les siga, dependiendo de la funcion, y si es la ultima funcion, 
las variables de ambiente. Puede que el programa aborte y tu shell 
resulte inutilizado a causa de las variables sobreescritas. 
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Hay dos tecnicas principales: saltar a un punto determinado del programa, 
y saltar hacia dentro del stack. 

Un ejemplo de la primera tecnica se muestra a continuacion. Si el atacante 
esta intentando burlar la siguiente validacion simple de nombre de usuario y 
contrasena, 

1 if (valid_user (usr, pass)) { 

2 /*(...)*/ 

3 } else { 

4 printf( "Error !\n") ; 

5 exit 1 ; 

6 } 



Y detecta que valid_user ( ) es susceptible a un desbordamiento, le bas- 
taria con incrementar en cuatro la direccion de retorno. La conversion de este 
if a ensamblador es, primero, saltar hacia la etiqueta valid_user, e ir (em- 
pleando al valor que esta regrese en%EBX) a la siguiente instruccion, o saltar a 
la etiqueta FAIL. Esto puede hacerse con la instruccion BNE $0, %EBX, FAIL 
{Branch if Not Equal, saltar si no es igual, que recibe como argumentos dos valo- 
res a ser comparados, en este caso el registro%EBX y el niimero 0, y la etiqueta 
destino, FAIL). Cambiar la direccion destino significa burlar la verificacion. 

Por otro lado, el atacante podrla usar la segunda tecnica para lograr que el 
sistema haga algo mas complejo — por ejemplo, que ejecute codigo arbitrario 
que el proporcione. Para esto, el ataque mas frecuente es saltar hacia adentro del 
stack. 



0x00000000 4- 



0xbffff9c0 



-► OxFFFFFFFF 
OxbffffSbS 



ai gc, at gv 



sfp 



ret 



buffei" 



4b Ob 256 bytes 
- OxbffffScO 



Figura 5.24: Ejecutando el codigo arbitrario inyectado al buffer. 



Para hacerlo, si en vez de proporcionar simplemente una cadena suficien- 
temente grande para sobrepasar el buffer se inyecta una cadena con codigo eje- 
cutable valido, y sobreescribiera la direccion de retorno con la direccion de su 
codigo dentro del buffer, tendrla 256 bytes de espacio para especificar codigo 
arbitrario. Este codigo tlpicamente se llama shellcode, pues se emplea para ob- 
tener un shell (un interprete de comandos) que ejecuta con los privilegios del 
proceso explotado. Este escenario se ilustra en la figura 5.24. 
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Mecanismos de mitigacion 

Claro esta, el mundo no se queda quieto. Una vez que estos mecanismos de 
ataque se dieron a conocer, comenzo un fuerte trabajo para crear mecanismos 
de mitigacion de danos. 

La principal y mas importante medida es crear ima cultura de programa- 
dores conscientes y practicas seguras. Esto cruza necesariamente el no emplear 
funciones que no hagan verificacion de limites. La desventaja de esto es que 
hace falta cambiar al factor humano, lo cual resulta practicamente imposible de 
lograr con suficiente profundidad.^^ Muchos desarrolladores esgrimen argu- 
mentos en contra de estas practicas, como la perdida de rendimiento que estas 
fimciones requieren, y muchos otros sencillamente nunca se dieron por entera- 
dos de la necesidad de programar correctamente. 

Por esto, se han ido creando diversos mecanismos automatizados de pro- 
teccion ante los desbordamientos de buffer. Ningimo de estos mecanismos es 
perfecto, pero si ayudan a reducir los riesgos ante los atacantes menos persis- 
tentes o habilidosos. 

Secciones de datos no ejecutables 

En secciones anteriores se describio la proteccion que puede unponer la 
MMU por regiones, evitando la modificacion de codigo ejecutable. 

En la arquitectura x86, dominante en el mercado de computadoras persona- 
les desde hace muchos anos, esta caracteristica existia en varios procesadores 
basados en el modelo de segmentacion de memoria, pero desaparecio al cam- 
biarse el modelo predominante por uno de memoria plana paginada, y fue 
hasta alrededor del 2001 en que fue introducida de vuelta, bajo los nombres 
bit NX (Never eXecute, nunca ejecutar) o bit XD (eXecute Disable, deshabilitar 
ejecucion), como una caracteristica particular de las extensiones pae. 

Empleando este mecanismo, la MMU puede evitar la ejecucion de codigo en 
el area de stack, lo cual anula la posibilidad de saltar al stack. Esta proteccion 
desafortunadamente no es muy efectiva: una vez que tiene acceso a im buffer 
vulnerable, el atacante puede saltar a libc, esto es, por ejemplo, proporcionar 
como parametro el nombre de un programa a ejecutar, e indicar como retomo 
la direccion de la funcion system o execve de la libc. 

Las secciones de datos no ejecutables son, pues, un obstaculo ante un ata- 
cante, aimque no representan una dificultad mucho mayor. 

Aleatotizacion del espacio de direcciones 

Otra tecnica es que, en tiempo de carga y a cada ejecucion, el proceso reciba 
diferentes direcciones base para sus diferentes areas. Esto hace mas difkil para 



^^El ejemplo mds claro de este problema es la funcibn gets, la cual sigue siendo ensenada y usada 
en los cursos bSsicos de programaci6n en C. 
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el atacante poder indicar a que direccion destino se debe saltan 

Un atacante puede emplear varias tecnicas para ayudarse a adivinar deta- 
lles acerca del acomodo en memoria de un proceso, y, con un buffer suficiente- 
mente grande, es comun ver cadenas de NOP, esto es, una extension grande de 
operaciones nulas, seguidas del shellcode, para aumentar las probabilidades de 
que el control se transfiera a un punto util. 

Empleo de canarios 

Se llama canario a un valor aleatorio de proteccion,^^ insertado entre los 
buffers y la direccion de retorno, que es verificado antes de regresar de una 
funcion. Si se presento un desbordamiento de buffer, el valor del canario sera 
reemplazado por basura, y el sistema podra detener la ejecucion del proceso 
comprometido antes de que brinde privilegios elevados al atacante. La figura 
5.25 ilustra este mecanismo. 



0x00000000 ^ 



-> OxFFFFFFFF 



qR'z2a&5f50s 



AAAAAAAAAAAAAAA. . 



argc, argv 



sfp 


ret 


canario 


buffer 



4b 4b 12 bytes 



256 bytes 



Figura 5.25: Marco de stack con im canario aleatorio protector de 12 bytes 
(qR' z2a&5f 50s): si este es sobreescrito por un buffer desbordado, se detendra 
la ejecucion del programa. 

Un atacante tiene dos mecanismos ante un sistema que requiere del canario: 
imo es el atacar no directamente a la funcion en cuestion, sino al manejador 
de senales que es notificado de la anomalla, y otro es, ya que se tiene acceso 
a la memoria del proceso, averiguar el valor del canario. Esto requiere ataques 
bastante mas sofisticados que los vistos en esta seccion, pero definitivamente 
ya no fuera del alcance de los atacantes. 

5.8.2. Ligado estatico y dinamico de bibliotecas 

Las bibliotecas de codigo (o simplemente bibliotecas) implementan el codigo de 
una serie de funcionalidades generales, que pueden ser usadas en diferentes 
programas y contextos. Un ejemplo clasico serla la biblioteca estandar de C, 
la cual ofrece funciones basicas de entrada/salida, manejo de cadenas, entre 
otras. 

^^Este uso proviene de la costumbre antigua de los mineros de tener un canario en una jaula en 
las minas. Como el canario es muy sensible ante la falta de oxigeno, si el canario moria servia como 
indicador a los mineros de que deblan abandonar la mina de inmediato, antes de correr la misma 
suerte. 
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A medida que el software crece en complejidad, los programadores recu- 
rren a la reutilizacion de codigo para aprovechar la implementacion de la funcio- 
nalidad que ofrecen las distintas bibliotecas. De esta forma, evitan "reinventar 
la rueda", y se concentran en la funcionalidad espedfica del software que estan 
construyendo. 

El concepto de ligado se refiere al proceso mediante el cual, se toma el codigo 
objeto de un programa junto con el codigo de las bibliotecas que este usa para 
crear un archivo ejecutable. De forma general hay dos tipos de ligado, que se 
explican a continuacion. 

El ligado estdtico consiste en tomar el codigo de una biblioteca e integrarlo 
al codigo del programa para generar el archivo ejecutable. Esto implica que 
cada programa tiene su propia copia del codigo de la biblioteca, lo cual puede 
causar un desperdicio de memoria y disco si hay muchos programas que usan 
la misma version. 

For su parte, en el ligado dindmico el codigo de las bibliotecas no se copia 
dentro de la imagen ejecutable del programa, pero requiere establecer algun 
mecanismo para informar que el programa necesita un codigo externo. Esto 
se puede implementar de diferentes formas. For ejemplo, se puede incluir un 
fragmento de codigo dentro del programa que usa la biblioteca denominado 
stub, el cual en tiempo de ejecucion solicita que se cargue la biblioteca requeri- 
da. Otra estrategia que se puede utilizar consiste en incluir algunas indicacio- 
nes que le permiten al sistema operativo, en el momento de crear el proceso, 
ubicar las bibliotecas que este requerira para su ejecucion. En cualqmer caso, 
el ligado dinamico busca que las bibliotecas solo sean cargadas cuando se las 
requiera. 

La figura 5.4 (p. 175, ilustra el momento en que ocurre cada uno de estos 
ligados: el ligado estatico es realizado por el editor de ligado, uniendo en ujn. 
solo modulo cargable al programa compilado {modulo objeto) con las bibliotecas 
{otros objetos); el ligado dinamico es realizado parciaLmente en tiempo de carga 
(para las bibliotecas del sistema) y parcialmente en tiempo de ejecucion (para las 
bibliotecas de carga dindmica)P 

Las bibliotecas y la seguridad 

El ligado dinamico puede traer consigo una serie de problemas, entre los 
cuales se destacan el manejo de versiones de las bibliotecas y potenciales vul- 
nerabilidades. El primer problema es conocido, en ambientes Windows, como 
el infierno de las DLL. este se puede causar de muchas formas. For ejemplo, si 
al instalar un nuevo programa, se instala tambien una version incompatible 
de ima biblioteca que es usada por otros programas. Esto causa que los demas 
programas no se puedan ejecutar, y lo que es mas, hace que la depiiracion del 



^''Refi&ase al libro Linkers and Loaders (ligadores y cargadores) de John R. Levine (1999) para 
mayores detalles respecto a este proceso. 
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fallo sea muy dificil. For otro lado, si no se tienen los controles suficientes, al 
desinstalar un programa se puede borrar una biblioteca compartida, lo cual 
puede llevar a que otros programas dejen de funcionar. 

El infiero de las DLL puede ser prevenido mediante estrategias como el ver- 
sionamiento de las biblioteca de ligado dinamico (esto es, hacer que cada com- 
ponente de las bibliotecas Ueve la version que implementa o nivel de compatibi- 
lidad que implementa),^^ y mediante el uso de scripts de instalacion o gestores 
de dependencias que verifican si en el sistema hay una version compatible de 
la biblioteca. Teniendo esta informacion, la biblioteca en cuestion se instalara 
linicamente en caso necesario. 

El ligado dinamico puede presentar problemas o vulnerabilidades debido 
a que el programa usa un codigo proporcionado por terceros, y confia en que 
la biblioteca funciona tal como se espera sin incluir codigo malicioso. Por tal 
razon, desde el punto de vista teorico bastaria que un atacante instale su propia 
version de una biblioteca para que pueda tener el control de los programas 
que la usan e incluso del mismo sistema operativo.^^ En el caso de bibliotecas 
ligadas estdticamente, dado que estas forman ya parte del programa, un atacante 
tendria que modificar al archivo objeto mismo del programa para alterar las 
bibliotecas. 

Asi las cosas, mas alia de la economla de espacio en memoria, ^como se ex- 
plica que sea tanto mas popular el ligado dinamico en los sistemas operativos 
modemos? 

Parte muy importante de la respuesta es la mantenibilidad: si es encontrado 
\m fallo en ima biblioteca de carga dinamica, basta con que los desarrolladores 
lo corrijan una vez (cuidando, claro, de mantener la compatibildad binaria) y 
reemplazar a dicha biblioteca en disco una sola vez. Todos los programas que 
liguen dinamicamente con esta biblioteca tendran disponible de irraiediato la 
version actualizada. En mucho sistemas operativos, el gestor de paquetes puede 
detectar cuales procesos en ejecucion emplean a determinada biblioteca dina- 
mica, y reiniciarlos de forma transparente al administrador. 

En contraste, de estar el fallo en una biblioteca de ligado estatico, el codigo 
afectado estaria incluido como parte de cada uno de los programas ligados con 
ella. Como consecuencia, para corregir este defecto, cada uno de los progra- 
mas afectados tendria que ser recompilado (o, por lo menos, religado) antes de 
poderse beneficiar de las correcciones. 

Y si bien este proceso resulta manual y tedioso para un administrador de 
sistemas con acceso a las fuentes de los programas que tiene instalados, resul- 
ta mucho mas oneroso aiin para quienes emplean software propietario (en la 

^''Este nivel de compatibilidad incluye no solo a la Interfax de aplicacion al programador (API, defi- 
nida en las secciones 2.7 y 2.7.1), sino tambien la interfaz de aplicacion binaria (ABl), esto es, no solo la 
informacion del nombre de las funciones que expone y los tipos de argumentos que reciben, sino 
tambien la ubicaci6n en memoria de su defrnici6n en un archivo ya compilado. 

^'Esto se puede lograr, por ejemplo, alterando la conflguraci6n del entomo en la cual el sistema 
busca las bibliotecas. 
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seccion A. 1.3 se aborda con mayor detenimiento lo que significa el software 
propietario en contraposicion al software libre). 

Cabe mencionar que el comportamiento del sistema ante la actualizacion de 
una biblioteca descrita ilustra una de las diferencias semanticas entre sistemas 
Windows y sistemas Unix que seran abordadas en el capitulo 6: mientras un 
sistema Unix permite la eliminacion de un archivo que estd siendo utilizado, Win- 
dows no la permite. Esto explica por que las actualizaciones de bibliotecas en 
sistemas Windows se aplican durante el proceso de apagado: mientras haya pro- 
cesos que tienen abierta una biblioteca, esta no puede ser reemplazada. Caso 
contrario en sistemas Unix, en que el archivo puede ser sustituido, pero mien- 
tras no sean reiniciados los procesos en cuestion, estos seguiran ejecutando la 
version de la biblioteca con el error. 

5.9. Ejercicios 

5.9.1. Preguntas de autoevaluacion 

1. Diagrame el acomodo del espacio en memoria de un proceso. ^Que dife- 
rencias principales y que similitudes tienen la seccion de datos con el espacio 
de libres (heap), y entre el espacio de libres con la pila (stack)? 

2. Un proceso en un sistema con arquitectura de memoria basada en la seg- 
mentacion tiene la sigmente tabla de segmentos: 

Segmento Inicio Tamano Permisos 



0 


240 


600 


RX 


1 


2 300 


16 


R 


2 


90 


100 


RW 


3 


1320 


950 


RW 


4 




96 


RX 



Para cada \ma de las siguientes solicitudes, indique que direccion flsica 
corresponderla, y -de ser el caso- que excepcion se genera. 

a) Lectura, 0-430 

b) Escritura, 0-150 

c) Lectura, 1-15 

d) Escritura, 2-130 

e) Ejecucion, 4-25 

3. El buffer de traduccion adelantada (tlb) de im sistema en particular pre- 
senta ima efectividad de 95%. Obtener im valor del TLB toma 10ns. La 
memoria principal tarda 120ns en recuperar ujn valor. ^Cual es el tiempo 
promedio para completar una operacion a memoria? 
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4. Con la siguiente cadena de referencia, y empleando cuatro marcos de 
memoria fisica, desarroUe la asignacion bajo los esquemas FIFO, OPT y 
LRU: 

1, 3, 2, 1, 5, 3, A, 1, 5, 2, 6, 7, 5, 7, 2, 5, 3, 5, 3, 1 

Asumiendo que cada fallo de pagina toma ocho milisegundos en ser aten- 
dido, ique diferencia en rendimiento puede observarse? 

5. Suponga un sistema paginado con un rango de direcciones de 4 GB 
(4 294 967 296 direcciones). 

■ iCuantas paginas tendra el sistema si se utilizan paginas de 4 096 
bytes? 

■ ^Que tamano (en bits) tendra una entrada de la tabla de traduccion? 
Suponga que solo se guarda el niimero de marco fisico. 

■ ^Que tamano tendra la tabla de paginacion si se desea cubrir todo el 
rango? 

■ Suponga que el tamano de la tabla de paginacion fuera demasiado 
grande. Proponga dos soluciones explicando ventajas y desventajas 
de cada una. 

6. Explique la relacion que hay entre direcciones virtuales y direcciones fi- 
sicas. Indique como se realiza la traduccion en los siguientes casos: 

■ Una computadora con TLB y tabla de paginacion de un nivel, con la 
entrada cargada en la TLB. 

■ Una computadora con TLB y tabla de paginacion de vn nivel y sin la 
entrada cargada. 

■ Una computadora sin TLB y con tabla de paginacion de dos niveles. 

■ Una computadora sin paginacion ni TLB pero con segmentadon. 

7. Un equipo presenta rendimiento muy deficiente. Ante un analisis de uti- 
lizacion a lo largo de un dia, se encuentra que el promedio de uso de CPU 
esta a 20% y el uso de la interfaz al disco diiro que aloja a la memoria 
virtual a 95%. ^En que condicion esta el sistema? 

Elija de la siguiente lista las dos respuestas que mayor efectividad tendrian 
para mejorar el rendimiento del sistema. Fundamente con una breve ex- 
plicacion. 

a) Reemplazar al CPU por uno 20% mas rapido (pasar de 1 GHz a 1.2 
GHz). 

b) Destinar un area del disco 25% mas grande para la memoria virtual 
(pasar de 4 a 5 GB). 
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c) Aumentar el grado de multiprogramacion en 10% (aumentar de 20 
a 22 los procesos en la cola de ejecucion). 

d) Reducir el grado de multiprogramacion en 10% (reducir de 20 a 18 
los procesos en la cola de ejecucion). 

e) Instalar uxi 25% mas de memoria principal (pasar de 2 a 2.5 GB). 

/) Instalar un disco duro un 33% mas rapido (cambiar ujn disco de 5 400 
RPM por uno de 7 200 RPM). 

8. Describa en que consiste un ataque de desbordamiento de pila {stack over- 
flow), y \m mecanismo de proteccion del sistema para contrarrestarlos. 
^Puede sugerir una manera en que un atacante podrla biurlar dicha pro- 
teccion? 

5.9.2, Temas de investigacion sugeridos 

Esquemas de asignacion de memoria en una realidad NUMA La realidad que 
se expuso en el capitulo respecto al multiprocesamiento simetrico como 

fuertemente dominante en relacion a los sistemas NUMA se mantiene cier- 
ta. . . Pero va cambiando rapidamente, y los sistemas NUMA son cada vez 
mas comuTies. 

Claro esta, la popularizacion de los sistemas NUMA tiene un alto efec- 
to en como se manejan los esquemas de administracion de memoria. Al 
entrar en juego la afinidad de cada proceso a un CPU dado, la administra- 
cion de la memoria y el planificador (despachador) de procesos quedan 
fuertemente interrelacionados. 

En el niimero de septiembre del 2013 de la revista "Communications of 
the ACM" aparece un articulo corto, conciso y bastante interesante, de 
Cristoph Lameter: "An overview of non-uniform memory access". Su- 
giero emplearlo como punto de partida. 

Cargado y ligado de programas Este tema ocupa un punto intermedio entre 
el estudio de los sistemas operativos y el de los compiladores. Para los 
lectores del presente libro, comprender este pimto comiin puede resultar 
de interes. 

Al convertir un programa escrito en determinado lenguaje de programa- 
cion por im humano en codigo ejecutable, no solo hay que convertir las 
instrucciones y proveer las abstracciones rnmimas, tambien es necesario 
que preparar al codigo para poder ser reubicado en la memoria. 

El proceso de cargado se refiere a como la imagen binaria del programa 
que esta grabada en un medio de almacenamiento es modificada al Ue- 
varse a memoria para adecuarse al espacio que le asigna el sistema ope- 
rativo; el proceso de ligado es como se maneja su integracion con las bi- 
bliotecas compartidas. 
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En este proceso entran temas como la gestion de memoria compartida, las 
indicaciones al compilador para generar codigo independiente de su posicion, 
etcetera. 

Mecanismos para mantener la coherencia en cache En un entorno multipro- 
cesador, el acceso concurrente a las mismas posiciones de memoria se 
vuelve muy complicado, por decir lo menos. Los distintos niveles de me- 
moria cache tienen que sincronizar su operacion (a altisima velocidad) y 
permitir que avancen los procesos compartiendo datos. 

Hay varios mecanismos para mantener la coherencia. Algiinas lineas pa- 
ra comenzar la investigacion pueden ser, para computadoras razonable- 
mente pequenas, los mecanismos fisgones (snoopy) de invalidacion y de 
actualizacion, y para equipos mas grandes, los mecanismos por hardwa- 
re de directorio; los protocolos/i'sgones son tambien conocidos por sus si- 
glas, o por las universidades donde fueron disenados: MSI, MESI (Illinois), 
MOSi (Berkeley), moesi y mesif. 

Relacion con sistemas operatives en use Este capltulo es probablemente el 
que mejor permite apreciar de forma directa la relacion entre los temas 
cubiertos y su manejo en un sistema operativo actual. Una manera sen- 
cilla de comprender el efecto de los diversos parametros del subsistema 
de memoria virtual es la empfrica: ^Como reacciona un sistema operati- 
vo de proposito general ante cambios en los distintos valores y umbrales; 
cuales serian las condiciones limite; que comportamientos esperarfamos 
llevando al sistema a estos extremos, y cuales encontramos en la realidad; 
como es la interfaz al administrador del sistema? 

Practicamente todos los sistemas operativos que se emplean hoy permi- 
ten ajustar estos valores, y la comparacion entre sistemas operativos dis- 
tintos segujramente resultara tambien interesante al lector; en el caso de 
Linux, se sugiere revisar la documentacion de los parametros de sysctl 
relativos a la memoria virtual. Estos estan documentados en: 

https://github.com/torvalds/linux/blob/master/Documentation/sysctl/vm.txt 

Otras categorias de vulnerabilidad Este capftulo presento el desbordamiento de 
pila, una de las vulnerabilidades clasicas y que mas se siguen explotando 
al dla de hoy. Se presentaron algunos mecanismos de mitigacion, pero la 
conclusion es lapidaria: la correcta proteccion de limites es de responsa- 
bilidad exclusiva e includible del desarrollador. 

Sin embargo, el desbordamiento de pila no es la unica vulnerabilidad. 
Hay varias viilnerabilidades relacionadas con el acomodo o el tamano 
especifico de los datos en la memoria. Dos ejemplos: 

■ En agosto del 2013, se descubrio lo que se popularize como ima cade- 
na Unicode de la muerte: un conjunto de caracteres que causa que cual- 
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quier programa que intente desplegarlos en pantalla en la Imea de 
productos Apple se caiga. El siguiente articulo, publicado por Chris 
Williams, relata el proceso que Uevo a averiguar, a partir del reporte 
defalla generado por el sistema y analizando el contenido de la me- 
moria que este reporta, como se puede encontrar un desbordamiento 
de entero. 

http:/ / www.theregister.co.uk/2013/ 09/ 04/ unicode_of_death_cras- 
h/ 

■ En abril de 2014 se dio a conocer un fallo en la biblioteca cripto- 
grafica OpenSSL, particularmente en la rutina que implementa el 
Heartbeat. Dada la gran base instalada de usuarios de OpenSSL, y lo 
sensible de la informacion que expone al atacante, desde su descu- 
brimiento se dio por hecho que esta es una de las vulnerabilidades 
con mayor efecto en escala mundial. Dado el renombre que implica 
descubrir una vulnerabilidad de este tamano, los descubridores de 
este fallo montaron el sitio http://heartbleed.com/ donde hay to- 
do tipo de ligas describiendo esta problematica; otro articulo que la 
explica muy claramente es: 

http:/ / www.theregister.co.ulc/ 2014/ 04/ 09/heartbleed_explained/ 

5.9.3. Lecturas relacionadas 

■ The Grumpy Editor goes 64-bit 

https : // lwn.net/Articles/7 903 6/ 

Jonathan Corbet (2004); Liniix Weekly News. Experiencia del editor de 
Linux Weekly News al migrar a una arquitectura de 64 bits en 2004. Lo 
mas interesante del articulo son los comentarios, ilustran buena parte de 
los pros y contras de una migracion de 32 a 64 bits. 

■ Using Valgrind to debug Xen Toolstacks 

http : / /www .hellion. org. uk/blog/post s /using- valgrind- on-xen- tool stacks/ 
Ian J. Campbell (2013). Presenta un ejemplo de uso de la herramienta 
Valgrind, para encontrar problemas en la asignacion, uso y liberacion de 
memoria en un programa en C. 

■ Process memory usage 

http : / /troysunix . blogspot . mx/2 Oll/OT/process-memory-usage . html 
ejemplos de pmap en diferentes Unixes 

■ Pdgina de manual de pmap en NetBSD 

http : / / www . daemon- systems . org/man/pmap . 1 . html 
Mas aUa de simplemente mostrar la operacion de una herramienta del 
sistema en Unix, esta pagina de manual ilustra claramente la estructura 
de la organizacion de la memoria. 
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■ Linkers and Loaders 

http : / /www . iecc . com/ linker/ 

John R. Levine (1999). Libro de libre descarga y redistribucion, dedicado 
a la tarea de los editores de ligado y el proceso de carga de los programas. 

■ An anomaly in space-time characteristics of certain programs running in a pa- 
ging machine 

http : / /dl . acm . org/ citation . cf m?doid=363011 .363155 
Belady, Nelson, Shedler (1969); Communications of the ACM 

■ Understanding the Linux Virtual Memory Manager 

http : / / ptgmedia .pears oncmg . com/ images/ 01314534 83/downloads/ gorman 
book . pdf 

Mel Gorman (2004). Libro de libre descarga y redistribucion, parte de la 
coleccion Bruce Perens' Open Source Series. Aborda a profundidad los me- 
canismos y algoritmos relatives a la memoria empleados por el sistema 
operative Linux. Entra en detalles tecnicos a profundidad, presentando- 
los poco a poco, por lo que no resulta demasiado complejo de leer. El 
primer tercio del libro describe los mecanismos, y los dos tercios restan- 
tes siguen el codigo comentado que los implementa. 

■ The art of picking Intel registers 

http : / /www . swansontec . com/ sregisters . html 
Wniiam Swanson (2003). 

■ The Tao of Buffer Overflows 

http : / /sistop . gwolf . org/biblio/The_Tao_of_Buf f er_Overf lows_-_ 
Enrique_Sanchez .pdf 

Enrique Sanchez (trabajo en proceso, facilitado por el autor) 

■ Smashing the Stack for fun and profit 

http : / /www .phrack . org/ issues . html?issue=4 9&id=14 

Aleph One (1996): Uno de los primeros artlculos publicados acerca de los 

buffers desbordados 

■ Attacking the Windows 7/8 Address Space Randomization 
http : / /kingcope . wordpress . com/ 2013/01/24/ 

Kingcopes (2013): Explica c6mo puede burlarse la proteccion ALSR (alea- 
torizacion de direcciones) en Windows 7 y 8, logrando mva direccion pre- 
decible de memoria hacia la cual saltan 

■ An overview of Non-Uniform Memory Access 

https : //dl .acm. org/citation.cfm?doid=25004 68 .2500477 
Cristoph Lameter (2013); Communications of the ACM 



Capitulo 6 

Organizacion de archives 



6.1. Introduccion 

De los papeles que cumple el sistema operative, probablemente el que mas 
consciente tengan en general sus usuarios es el de la gestion del espacio de al- 
macenamiento, esto es, la organizacion de la informacion en ujn sistema de archi- 
ves . Al dia de hoy, todos los usuarios de equipo de computo dan por sentado y 
comprenden a grandes rasgos la organizacion del espacio de aLmacenamiento 
en \m directorio jerarquico, con iinidades de almacenamiento Uamadas archives, 
de diferentes tipos segiin su funcion. En el presente capitulo se revisara la se- 
mantica que compone a este modelo, para que en el capitulo 7 se continue con 
los detalles de la gestion del espacio fisico donde estos estan alojados. 

La abstraccion que hoy se conoce como sistemas de archivos es una de las 
que mas tiempo ha vivido y se ha mantenido a lo largo de la historia de la 
computacion, sobreviviendo a lo largo de practicamente todas las generacio- 
nes de sistemas operativos. Sin embargo, para poder analizar como es que el 
sistema operative representa la informacion en el dispositive fisico, el presente 
capitulo inicia discutiendo como es que esta informacion es comprendida por 
los niveles mas altos — ^por los programas en espacio de usuario. 

La informadon cruda tiene que pasar una serie de transformaciones. Yendo 
de niveles superiores a los mas bajos, im programa estructura sus datos en 
archivos, siguiendo elformato que resulte mas pertinente al tipo de informacion 
a representar. Un conjunto de archivos hoy en dia es tlpicamente representado 
en una estructura de directorios} 

Cada dispositive empleado para aLmacenar archivos tiene un directorio. 
Cuando un sistema opera con mas de im dispositive fisico, hay principalmen- 
te dos mecanismos para integrar a dichos dispositivos en un sistema de archivos 

^Se tienen otros mecanismos para su organizaci6n, pero 6stos no estdn tan ampUamente difun- 
didos. 
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Espacio de usuario 



Aplicaciones 



Bibliotecas del sistema 




Llamadas al sistema 



Sistema de archivos virtual 




SIstemas de archivos 





Subsistema de entrada y salida 




Figura 6.1: Capas de abstraccion para implementar los sistemas de archivos. 

virtual^ brindando al usuario una interfaz uniforme. For ultimo, los archivos 
son una estructura meramente logica; deben ser convertidos para ser represen- 
tados en un dispositivo de bloques como los diversos tipos de unidades -aunque 
esta nomenclatura es a veces incorrecta- como discos. Este ultimo paso sera 
abordado en el capitulo 7. 

Del diagrama presentado en la figura 6.1, toca al objeto de estudio de esta 
obra -el sistema operativo- recibir del espacio de usuario las llamadas al sis- 
tema que presentan la interfaz de archivos y directorios, integrar el sistema de 
archivos virtual y traducir la informacion resultante a un sistema de archivos. 

Cabe mencionar que varias de las capas aqui presentadas podrian perfec- 
tamente ser subdivididas, analizadas por separado, e incluso tratarse de forma 
completamente modular — de hecho, este es precisamente el modo en que se 
implementan de forma transparente caracteristicas hoy en dia tan comunes co- 
mo sistemas de archivos en red, o compresion y cifrado de la informacion. Una 
referenda mas detallada acerca de ventajas, desventajas, tecnicas y mecanis- 
mos de la division y comunicacion entre capas puede ubicarse en el articiilo de 
Heidemann y Popek (1994). 

^Esto serS abordado en la secci6n 6.3.3. 
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6.2. Concepto de archive 

En primer termino, un archive es un /tipo de datos abstracto/ — esto es, 
podria verse como una estructura que exclusivamente permite la manipulacion 
por medio de vina interfaz orientada a objetos: los procesos en el sistema solo 
pueden tener acceso a los archivos por medio de la interfaz ofrecida por el 
sistema operativo.^ La siguiente seccion describe las principales operaciones 
provistas por esta interfaz. 

Para el usuario, los archivos son la unidad logica minima al hablar de aLma- 
cenamiento: todo el almacenamiento persistente (que sobrevive en el tiempo, 
sea a reinicios del sistema, a perdida de corriente o a otras circunstancias en 
el transcurso normal de ejecucion) en el sistema al que tiene acceso, se efec- 
tiia dentro de archivos; el espacio libre en los diferentes dispositivos no tiene 
mayor presencia fuera de saber que esta potencialmente disponible. 

Dentro de cada volumen (cada medio de almacenamiento), los archivos dis- 
ponibles conforman un directorio, y son tipicamente identificados por un nom- 
bre o \ma ruta. Mas adelante se presentaran de las diferentes construcciones 
semanticas que pueden conformar a los directorios. 

6.2.1. Operaciones con archivos 

Cada sistema operative definira la interfaz de archivos acorde con su se- 
mantica, pero en Imeas generales, las operaciones que siempre estaran dispo- 
nibles con un archivo son: 

Borrar Elimina al archivo del directorio y, de ser procedente, libera el espacio 
del dispositivo 

Abrir Solicita al sistema operative verificar si el archivo existe o puede ser 
creado (dependiendo del modo requerido) y se cuenta con el acceso para 
el modo de acceso al archivo indicado y si el medio lo soporta (por ejemplo, 
a pesar de contar con todos los permisos necesarios, el sistema operativo 
no debe permitir abrir para escritura un archivo en vin CD-ROM u otro 
medio de solo lectura). En C, esto se hace con la funcion f open ( ) . 

Al abrir un archivo, el sistema operativo asigna im descriptor de archivo 
que identifica la relacion entre el proceso y el archivo en cuestion; estos 
seran definidos propiamente en la seccion 6.2.2. 

Todas las operaciones descritas a continuacion operan sobre el descriptor 
de archivo, no con su nombre o ruta. 

'Como se verd en la seccibn 7.1.3, esto no es necesariamente asl, sin embargo, el uso de los dis- 
positivos en crudo es muy bajo. Este capltulo estA enfocado exclusivamente al uso estructurado en 
sistemas de archivos. 
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Cerrar Indica al sistema que el proceso en cuestion termino de trabajar con el 
archive; el sistema entonces debe escribir los buffers a disco y eliminar la 
entrada que representa a esta combinacion archivo-proceso de las tablas 
activas, invalidando al descriptor de archivo. En C, para cerrar un descrip- 
tor de archivo se usa f close { ) . 

Dado que todas las operaciones se realizan por medio del descriptor de 
archivo, si un proceso cierra un archivo y requiere seguir utilizandolo, 
tendra que abrirlo de nuevo para obtener un nuevo descriptor. 

Leer Si se solicita al sistema la lectura leer de un archivo hacia determinado 
buffer, este copia el siguiente pedazo de informacion al. Este pedazo podria 
ser una Ifnea o un bloque de longitud definida, dependiendo del modo 
en que se solicite la lectura. El sistema mantiene im apimtador a la ultima 
posicion leida, para poder continuar con la lectura de forma secuencial. 

La funcion que implementa la lectura en C es f read ( ) . Cabe mencionar 
que f read ( ) entrega el numero de caracteres especificado; para trabajar 
con Ifneas de texto hace falta hacerlo mediante bibliotecas que implemen- 
ten esta funcionalidad, como readline. 

Escribir Teniendo un archivo abierto, guarda informacion en el. Puede ser que 
escriba desde su primer posicion (truncando al archivo, esto es, borrando 
toda la informacion que pudiera ya tener), o agregando al archivo, esto es, 
iniciando con el apuntador de escritura al final del mismo. La funcion C 
para escribir a un descriptor de archivo es f write ( ) . 

Reposicionar Tanto la lectura como la escritura se hacen siguiendo un apunta- 
dor, que indica cual fue la ultima posicion del archivo a la que acceso el 
proceso actual. Al reposicionar el apuntador, se puede saltar a otro punto 
del archivo. La funcion que reposiciona el apuntador dentro de im des- 
criptor de archives es f seek ( ) . 

Hay varias otras operaciones comunes que pueden implementarse con Ua- 
madas compuestas a estas operaciones (por ejemplo, copiar un archivo puede 
verse como crear un archivo nuevo en modo de escritura, abrir en modo de lec- 
tura al archivo fuente, e ir leyendo de este y escribiendo al nuevo hasta llegar al 
fin de archivo fuente). 

Las operaciones aqul presentadas no son todas las operaciones existentes; 
dependiendo del sistema operative, habra algunas adicionales; estas se presen- 
tan como una base general comiin a los principales sistemas operatives. 

Vale la pena mencionar que esta semantica para el maneje de archives pre- 
senta a cada archivo como si fuera una unidad de cinta, dentro de la cual la 
cabeza lectera/escritera simulada puede avanzar o retreceder. 
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6.2.2. Tablas de archivos abiertos 

Tanto el sistema operative como cada uno de los procesos mantienen nor- 
malmente tablas de archivos abiertos. Estas mantienen informadon acerca de to- 
dos los archivos actualmente abiertos, presentandolos hacia el proceso por me- 
dio de \m descriptor de archivo; una vez que un archive fue abierto, las opera- 
ciones que se realizan dentro de este no son empleando su nombre, sino su 
descriptor de archivo. 

En un sistema operative multitareas, mas de un proceso podria abrir el mis- 
mo archivo a la vez; lo que cada uno de ellos pueda hacer, y como esto repercu- 
te en lo que vean los demas procesos, depende de la semantica que implemente 
el sistema; ujn. ejemplo de las diferentes semanticas posibles es el descrito en la 
seccion 6.2.3. 

Ahora, ipor que estas tablas se mantienen tanto por el sistema operative co- 
mo por cada uno de los procesos, no Ueva esto a una situacion de informacion 
redundante? 

La respuesta es que la informacion que cada uno debe manejar es distinta. 
El sistema operative necesita: 

Conteo de usuarios del archivo Requiere saberse cuantos procesos estan em- 
pleando en tede memento a determinade archive. Este permite, per 
ejemplo, que cuando el usuario solicite desmontar una particion (puede 
ser para expulsar una unidad remevible) e eliminar un archive, el siste- 
ma debe peder determinar cuando es memento de declarar la selicitud 
como efectuada. Si algun proceso tiene abierto un archive, y particular- 
mente si tiene cambies pendientes de guardar, el sistema debe hacer lo 
posible por evitar que el archivo desaparezca de su vision. 

Modos de acceso Aunque un usuario tenga permises de acceso a determinade 
recurso, el sistema puede determinar negarlo si llevaria a una inconsis- 
tencia. Per ejemplo, si dos procesos abren un mismo archivo en modo de 
escritura, es probable que los cambies que realice uno sobreescriban a los 
que haga el etro. 

Ubicacion en disco El sistema mantiene esta infremacion para evitar que cada 
proceso tenga que consultar las tablas en disco para encontrar al archivo, 
e cada uno de sus fragmentes. 

Informacion de bloqueo En case de que los modos de acceso del archive re- 
quieran proteccion mutua, puede hacerlo por medio de im bloqueo. 

Por etro lade, el proceso necesita: 

Descriptor de archivo Relacion entre el nombre del archive abierto y el identi- 
ficador numerico que maneja intemamente el proceso. Un archivo abierto 
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por varios procesos tendra descriptores de archivo distintos en cada uno 
de ellos. 

Al detallar la implementacion, el descriptor de archivo otorgado por el 
sistema a un proceso es simplemente un niimero entero, que podria en- 
tenderse como el n-esimo archivo empleado por el proceso.^ 

Permisos Los modos validos de acceso para un archivo. Esto no necesaria- 
mente es igual a los permisos que tiene el archivo en cuestion en disco, 
sino que el subconjunto de dichos permisos bajo los cuales esta operando 
para este proceso en particular — si un archivo fue abierto en modo de 
solo lectura, por ejemplo, este campo linicamente permitira la lectura. 

6.2.3. Acceso concurrente: bloqueo de archivos 

Dado que los archivos pueden emplearse como mecanismo de comunica- 
cion entre procesos que no guarden relacion entre si, incluso a lo largo del 
tiempo, y para emplear un archivo basta indicar su nombre o ruta, los siste- 
mas operativos multitarea implementan mecanismos de bloqueo para evitar 
que varios procesos intentando emplear de forma concurrente a un archivo se 
corrompan mutuamente. 

Algunos sistemas operativos permiten establecer bloqueos sobre determi- 
nadas regiones de los archivos, aunque la semantica mas comun es operar so- 
bre el archivo entero. 

En general, la nomenclatura que se sigue para los bloqueos es: 

Compartido {Shared lock) Podria verse como equivalente a un bloqueo (o can- 
dado) para realizar lectura — varios procesos pueden adquirir al mismo 
tiempo un bloqueo de lectura, e indica que todos los que posean dicho 
candado tienen la expectativa de que el archivo no sufrira modificaciones. 

Exclusivo (Exclusive lock) Un bloqueo o candado exclusivo puede ser adquirido 
por un solo proceso, e indica que realizara operaciones que modifiquen 
al archivo (o, si la semantica del sistema operativo permite expresarlo, a 
la porcion del archivo que indica). 

Respecto al mecanismo de bloqueo, hay tambien dos tipos, dependiendo de 
que tan explfcito tiene que ser su manejo: 

Mandatorio u obligatorio (Mandatory locking) Una vez que un proceso ad- 
quiere \m candado obligatorio, el sistema operativo se encargara de im- 
poner las restricciones corresponidentes de acceso a todos los demas pro- 

*No s61o los archivos reciben descriptores de archivo. Por ejemplo, en todos los principales 
sistemas operativos, los descriptores 0, 1 y 2 estin relacionados a flujos de datos: respectivamente, la 
entrada esttodar (STDIN), la salida est&idar (STDOUT) y el error estdndar (STDERR); si el usuario 
no lo indica de otro modo, la terminal desde donde fue ejecutado el proceso. 



6.2. CONCEPTODEARCHIVO 



233 



cesos, independientemente de si estos fueron programados para conside- 
rar la existencia de dicho bloqueo o no. 

Consultivo o asesor {Advisory locking) Este tipo de bloqueos es manejado 
cooperativamente entre los procesos involucrados, y depende del pro- 
gramador de cada uno de los programas en cuestion el solicitar y respetar 
dicho bloqueo. 

Haciendo un paralelo con los mecanismos presentados en el capitulo 3, los 
mecanismos que emplean mutexes, semaforos o variables de condicion serian 
consultivos, y linicamente los que emplean monitores (en que la linica manera 
de llegar a la informacion es por medio del mecanismo que la protege) serian 
mandatorios. 

No todos los sistemas operativos implementan las cuatro posibles combina- 
ciones (compartido mandatorio, o compartido compulsivo, exclusivo manda- 
torio y exclusivo consultivo). Como regla general, en los sistemas Windows se 
maneja un esquema de bloqueo obligatorio, y en sistemas Unix es de bloqueo 
consultivo.^ 

Cabe mencionar que el manejo de bloqueos con archivos requiere del mis- 
mo cuidado que el de bloqueo por recursos cubierto en la seccion 3.4: dos pro- 
cesos intentando adquirir un candado exclusivo sobre dos archivos pueden 
caer en un bloqueo mutuo tal como ocurre con cualquier otro recurso. 

6.2.4. Tipos de archive 

Si los archivos son la unidad logica minima con la que se puede guardar infor- 
macion en aLmacenamiento secundario, naturalmente sigue que hay archivos 
de diferentes tipos: cada uno podria ser un documento de texto, un binario 
ejecutable, un archivo de audio o video, o un larguisimo etcetera, e intentar 
emplear un archivo como uno de un tipo distinto puede resultar desde una 
frustracion al usuario porque el programa no responde como este quiere, hasta 
en perdidas economicas.^ 

Hay tres estrategias principales para que el sistema operativo reconozca el 
tipo de un archivo: 

Extension En los sistemas CP/M de los setenta, el nombre de cada archivo se 
dividla en dos porciones, empleando como elemento separador al pimto: 
el nombre del archivo y su extension. El sistema mantema una lista de 

^Esto explica el que en Windows sea tan comiin que el sistema mismo rechace hacer determi- 
nada operacion porque cl archivo estd abierto por otro programa (bloqueo mandatorio compartido), 
mientras que en Unix esta responsabilidad recae en cada uno de los programas de aplicacion. 

^Por ejemplo, imprimir im archivo binario resulta en una gran cantidad de hojas inutiles, par- 
ticularmente tomando en cuenta que hay caracteres de control como el ASCII 12 (avance de forma, 
formfeed), que Uevan a las impresoras que operan en modo texto a iniciar una nueva p^gina; Uevar 
a un usuario a ejecutar im archivo ejecutable disfrazado de im dociimento inocuo, como se verd a 
continuaci6n, fue un importante vector de infecci6n de muchos virus. 



234 



CAPITULO 6. ORGANIZACION DE ARCHIVOS 



extensiones conocidas, para las cuales sabria como actuar, y este diseno se 
propagaria a las aplicaciones, que solo abririan a aquellos archivos cuyas 
extensiones supieran manejar. 

Esta estrategia fue heredada por VMS y MS-DOS, de donde la adopto Win- 
dows; ya en el contexto de un entorno grafico, Windows agrega, mas alia 
de las extensiones directamente ejecutables, la relacion de extensiones 
con los programas capaces de trabajar con ellas, permitiendo invocar a 
un programa con solo dar "doble clic" en un archivo. 

Como nota, este esquema de asociacion de tipo de archivo permite ocul- 
tar las extensiones toda vez que ya no requieren ser del conocimiento 
del usuario, sino que son gestionadas por el sistema operativo, abre una 
via de ataque automatizado que se popularize en su momento: el envfo 
de correos con extensiones enganosas duplicadas, esto es, el programa 
maligno (un programa troyano) se envia a todos los contactos del usuario 
infectado, presentandose por ejemplo como una imagen, con el nombre 
inocente . png . exe. Por el esquema de ocultamiento mencionado, este 
se presenta al usuario como inocente .png, pero al abrirlo, el sistema 
operativo lo reconoce como mv ejecutable, y lo ejecuta en vez de abrirlo 
en ujn visor de imagenes. 

Ntimeros magicos La altemativa que emplean los sistemas Unix es, como 
siempre, simple y elegante, aunque indudablemente presenta eventuales 
lagunas: el sistema mantiene una lista compilada de las huellas digitales de 
los principales formatos que debe manejar,'' para reconocer el contenido 
de un archivo basado en sus primeros bytes. 

Casi todos los formatos de archivo incluyen lo necesario para que se Ueve 
a cabo este reconocimiento, y cuando no es posible hacerlo, se intenta por 
medio de ciertas reglas heuristicas. Por ejemplo, todos los archivos de ima- 
gen enformato de intercambio grafico (GIF) inician con la cadena GlF87a o 
GIFS 9a, dependiendo de la version; los archivos del lenguaje de des- 
cripcion de paginas PostScript inician con la cadena% ! , el Formato de Do- 
cumentos Portdtiles (PDF) con%PDF, un documento en formatos definidos 
alrededor de XML inicia con < ! DOCTYPE, etcetera. Algunos de estos for- 
matos no estan anclados al inicio, sino en un pimto especifico del primer 
bloque. 

Un caso especial de niimeros magicos es el Uamado hashbang (# !). Es- 
to indica a un sistema Unix que el archivo en cuestion (tfpicamente 
un archivo de texto, incluyendo codigo fuente en algun lenguaje de 
script) debe tratarse como un ejecutable, y empleando como interprete 
al comando indicado inmediatamente despues del hashbang. Es por es- 
to que se pueden ejecutar directamente, por ejemplo, los archivos que 

''Una de las ventajas de este esquema es que cada adininistrador de sistema puede ampliar la 
Usta con las huellas digitales que requiera localmente. 
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inician con #!/usr/bin/bash:el sistema operativo invoca al programa 
/usr /bin/bash, y le especifica como argumento al archivo en cuestion. 

Metadatos externos Los sistemas de archivos empleado por las Apple Macin- 
tosh desde 1984 separan en dos divisiones (forks) la informacion de un ar- 
chivo: los datos que propiamente constituyen al archivo en cuestion son 

la division de datos {data fork), y la informacion acerca del archivo se guar- 
dan en una estructura independiente Uamada division de recursos {resource 
fork). 

Esta idea resulto fundamental para varias de las caracteristicas amigables 
al usuario que presento Macintosh desde su introduccion, particularmen- 
te, para presentar ujn entorno grafico que respondiera agilmente, sin tener 
que buscar los datos base de una aplicacion dentio de un archivo de mu- 
cho mayor tamano. La division de recursos cabe en pocos sectores de disco, 
y si se toma en cuenta que las primeras Macintosh funcionaban unica- 
mente con discos flexibles, el tiempo invertido en leer una lista de iconos 
podria ser demasiada. 

La division de recursos puede contener todo tipo de informacion; los pro- 
gramas ejecutables son los que le dan un mayor uso, dado que incluyen 
desde los aspectos graficos (icono a mostrar para el archivo, ubicacion de 
la ventana a ser abierta, etc.) hasta aspectos funcionales, como la tiaduc- 
cion de sus cadenas al lenguaje particular del sistema en que esta instala- 
do. Esta division permite una gran flexibilidad, dado que no es necesario 
tener acceso al fuente del programa para crear traducciones y temas. 

En el tema particular que concieme a esta seccion, la division de recursos 
incluye un campo llamado creador, que indica cual programa fue el que 
genero al archivo. Si el usuario solicita ejecutar un archivo de datos, el 
sistema operativo lanzarla al programa creador, indicandole que abra al 
archivo en cuestion. 

Las versiones actuales de MacOS ya no emplean esta tecnica, sino que ima 
llamada appDirectory, para propositos de esta discusion, la tecnica base es 
la misma. 

6.2,5. Estructura de los archivos y metodos de acceso 

La razon principal del uso de sistemas de archivos son, naturalmente, los ar- 
chivos. En estos se aknacena informacion de algiin tipo, con o sin una estructura 
predeterminada. 

La mayor parte de los sistemas operativos maneja unicamente archivos sin 
estructura — cada aplicacion es responsable de preparar la informacion de for- 
ma congruente, y la responsabilidad del sistema operativo es unicamente en- 
tiegarlo como un conjimto de bytes. Historicamente, hubo sistemas operativos. 
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como IBM CICS (1968), IBM MVS (1974) o dec vms (1977), que administraban 
ciertos tipos de datos en un formato basico de base de datos. 

El hecho de que el sistema operative no imponga estructura a un archivo 
no significa, claro esta, que la aplicacion que lo genera no lo haga. La razon 
por la que los sistemas creados en los ultimos 30 anos no han implementado 
este esquema de base de datos es que le resta flexibilidad al sistema: el que una 
aplicacion tuviera que cenirse a los tipos de datos y alineacion de campos del 
sistema operative impedia su adecuacion, y el que la funcionalidad de un ar- 
chivo tipo base de datos dependiera de la version del sistema operative creaba 
\m acoplamiento demasiado rigido entre el sistema operative y las aplicacienes. 

Esta practica ha ide cediende terrene para dejar esta respensabilidad en 
manes de preceses independientes en espacie de usuarie (come serfa im gester 
de bases de datos tradicienal), e de biblietecas que ofrezcan la funcionalidad de 
manejo de archives estructurades (come en el case de SQLite, empleade tanto 
per herramientas de adquisicion de dates de bajo nivel come systemtap come 
per herramientas tan de escriterie come el gester de fetegraflas shotwell o el 
navegador Firefox). 

En los sistemas derivades de MS-DOS puede verse aun un remanente de 
los archives estructurades: en estos sistemas, un archivo puede ser de texto o 
binario. Un archivo de texto esta compuesto por una serie de caracteres que 
ferman Itneas, y la separacion entre una Irnea y etra constituye de un retorno de 
carro (caracter ASCII 13, CR) seguide de un salto de Imea (caracter ASCII 10, LF).^ 

El accese a los archives puede realizarse de diferentes maneras: 

Acceso secuencial Mantiene la semantica per medio de la cual permite leer de 
los archives, de forma equivalente a como lo harian las unidades de cinta 
mencionadas en la seccion 6.2.1, y como lo ilustra la figura 6.2: el me- 
canismo principal para leer e escribir es ir avanzande censecutivamente 
per los bytes que conforman al archivo hasta llegar a su final. 

Tipicamente se emplea este mecanismo de lectura para leer a memeria 
codige (pregramas e biblietecas) e decumentes, sean enteres e fraccienes 
de los mismos. Para \m contenido estructurado, como una base de datos, 
resultarfa abselutamente ineficiente, dado que no se cenece el punte de 
inicio o finalizacion de cada une de los registres, y probablemente seria 
necesario hacer barridos secuenciales del archivo complete para cada una 
de las biisquedas. 



'^Esta logica es herencia de las maquinas de escribir manuales, en que el salto de Imea (avanzar 
el rodillo a la Imea siguiente) era una operacion distinta a la del retorno de carro (devolver la cabeza 
de escrituia al inicio de la llnea). En la epoca de los teletipos, como medida para evitar que se 
perdieran caracteres mientras la cabeza volvia hasta la izquierda, se decidi6 separar el inicio de 
nueva llnea en los dos pasos que tienen las mdquinas de escribir, para inducir ima demora que 
evitara la p6rdida de informaci6n. 
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. . . Nombi e##Gonzalo; Apellido##Oliva; Nombi'e##Raqueli Apellido##Domrnguez: E. . . 



Figura 6.2: Archive de acceso secuencial. 

Acceso aleatorio El empleo de gestores como SQLite u otros muchos motores 

de base de datos mas robustos no exime al usuario de pensar en el archi- 
ve como una tabla estructurada, como lo ilustra la figura 6.3. Si la linica 
semantica por medio de la cual el sistema operativo permitiera trabajar 
con los archivos fuera la equivalente a una unidad de cinta, implementar 
el acceso a im pimto determinado del archivo podria resultar demasiado 
costoso. 

Afortimadamente, que el sistema operativo no imponga registros de lon- 
gitud fija no impide que el programa gestor lo haga. Si en el archivo al 
cual apunta el descriptor de archivo FD hay 2 000 registros de 75 by- 
tes cada uno y el usuario requiere recuperar el registro numero 65 hacia 
el buffer registro, puede reposicionar el apuntador de lectura al byte 
65 X 75 = 4 875 (seek (FD, 4875) ) y leer los siguientes 75 bytes en 
registro (read (FD, *registro, 75)). 
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Figura 6.3: Archivo de acceso aleatorio. 

Acceso relative a indice En los liltimos anos se han popularizado los gestores 
de base de datos debilmente estructurados u orientados a documentos, llama- 
dos genericamente NoSQh. Estos gestores pueden guardar registros de 
tamano variable en disco, por lo que, como lo ilustra la figura 6.4, no 
pueden encontrar la ubicacion correcta por medio de los mecanismos de 
acceso aleatorio. 

Para implementar este acceso, se divide al conjunto de datos en dos sec- 
ciones (incluso, posiblemente, en dos archivos independientes): la pri- 
mer seccion es una lista corta de identificadores, cada vino con el punto 
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de inicio y termino de los datos a los que apunta. Para leer un registro, 
se emplea acceso aleatorio sobre el mdice, y el apuntador se avanza a la 
ubicacion espedfica que se solicita. 

En el transcurso de un uso intensive de esta estructura, dado que la por- 
cion de mdice es muy frecuentemente consultada y relativamente muy 
pequena, muy probablemente se mantenga completa en memoria, y el 
acceso a cada uno de los registros puede resolverse en tiempo muy bajo. 

La principal desventaja de este modelo de indexacion sobre registros de 
longitud variable es que solo resulta eficiente para contenido mayormente 
de lectura: cada vez que se produce una escritura y cambia la longitud de 
los datos almacenados, se va generando fragmentacion en el archivo, y 
para resolverla frecuentemente se hace necesario suspender un tiempo 
la ejecucion de todos los procesos que lo esten empleando (e invalidar, 
claro, todas las copias en cache de los indices). Ahora bien, para los casos 
de uso en que el comportamiento predominante sea de lectura, este for- 
mato tendra la ventaja de no desperdiciar espacio en los campos nulos o 
de valor irrelevante para algunos de los registros, y de permitir la flexi- 
bilidad de registrar datos originalmente no contemplados sin tener que 
modificar la estructura. 

Es importante recalcar que la escritura en ambas partes de la base de 
datos (fndice y datos) debe mantenerse con garantias de atomicidad — 
si se pierde la sincronla entre ellas, el resiiltado sera una muy probable 
corrupcion de datos. 
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Figura 6.4: Acceso relativo a Indice: tabia con apuntadores al lugar justo en un 
archivo sin estructura. 



6.2.6. Archives especiales 



Los sistemas de archivos son estructuras de tan facil manejo y compren- 
sion que resulta natiiral que los disenadores de sistemas operativos buscaran 



6.2. CONCEPTODEARCHIVO 



239 



aprovecharlos para presentar todo tipo de estructuras, no solo archivos. En este 
sentido, la maxima Unix, todo es un archivo, resulta el ejemplo natural. 

Este concepto fue brevemente presentado en la seccion 2.8; complementan- 
do dicha seccion, en un sistema Unix estandar, uxi archivo puede pertenecer a 
las siguientes categorias: 

Archivo estandar Aunque suene obvio, el tipo basico de archivo es, precisa- 
mente, el archivo. Representa directamente la informacion que lo confor- 
ma. Su semantica de uso es la presentada en el transcurso de este capitu- 
lo. 

Objetos del sistema de archivos La informacion acerca del sistema de archi- 
vos se almacena tambien dentro de archivos, aunque su tratamiento es 
especial (con una reminiscencia de los sistemas historicos mencionados 
en la seccion 6.2.5): El sistema operativo oculta al archivo real, y gestio- 
na su informacion procesada para que lo emplee el usuario. Este tipo de 
archivos puede referirse a directorios o a ligas simbolicas. Ambos se de- 
tallan en la seccion 6.3.1. 

Dispositivos Permiten el acceso directo a un dispositivo externo. Como fue 
presentado en la seccion 2.8, pueden ser de hloques o de caracteres. El con- 
tenido del archivo son dos mimeros, el mayor y el menor; tradicionalmen- 
te, el mayor indica de que clase de dispositivo se trata, y el menor, la 
instancia de que se trata. 

For ejemplo, tanto los discos duros como sus particiones Uevan por nii- 
mero mayor el ocho; los mimeros menores para los duros son 0, 16, 32, 
48. Cada uno de los discos puede tener hasta 15 particiones: 1 a 15, 17 a 
31, etcetera. 

Comunicacion entre procesos Los archivos pueden representar tuberias nom- 
bradas y sockets. Ambos son mecanismos que permiten intercambiar in- 
formacion entre distintos procesos; la tuberia nombrada es mas sencilla 
de emplear, pero permite linicamente la comunicacion unidireccional, en 
tanto que el socket permite comunicacion bidireccional como si se tratara 
de ima conexion por red. 

6.2.7. Transf erencias orientadas a bloques 

Un sistema de archivos es la representacion que se da a un conjunto de ar- 
chivos y directorios sobre un dispositivo de bloques, esto es, un dispositivo que, 
para cualquier transferencia solicitada desde o hacia el, respondera con un blo- 
que de tamano predefinido. 

Esto es, si bien el sistema operativo presenta una abstraccion por medio 
de la cual la lectiira (read ( ) ) puede ser de wx tamano arbitrario, todas las 
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transferencias de datos desde cualquiera de los discos seran de un multiplo 
del tamano de bloques, definido por el hardware (tipicamente 512 bytes). 

Al leer, como en el ejemplo anterior, solamente un registro de 75 bytes, el 
sistema operative lee el bloque complete y probablemente lo mantiene en un 
cache en la memoria principal; si en vez de una lectura, la operacion efectuada 
fue una de escritura (write ()), y el sector a modificar no ha sido leido aiin 
a memoria (o fue leido hace mucho, y puede haber sido expirado del cache), 
el sistema tendra que leerlo nuevamente, modificarlo en memoria, y volver a 
guardarlo a disco. 

6.3. Organizacion de archives 

Hasta este punto, el enfoque ha sido en que es y como se maneja un archive. 
Sin embargo, no tendria sentido hablar de sistemas de archivos si no hubiera una 
gran cantidad de archivos. Es comiin que im solo medio de almacenamiento 
de im eqmpo de use casere aleje decenas de miles de archivos, y en equipos 
dedicades, no esta fuera de lugar tener cientes e miles de veces tanto. Per tante, 
se tiene que ver tambien come organizar wna gran cantidad de archives. 

6.3.1. Evolucion del concepto de directorio 

El concepto deminante en almacenamiento hey en dla es el de directorios je- 
rdrquicos. Este no siempre fue asi; cenviene revisar brevemente su historia para 
explicar la razon de ciertes detalles de implementacion del esquema actual- 
mente deminante. 

Convenciones de nomenclatura 

Cada sistema de archivos puede determinar cuantes y que caracteres son 
validos para designar a uno de sus elementos, y cuales son separadores vali- 
dos. El caracter que se emplea para separar los elementos de un directorio no 
es un estandar a traves de tedes los sistemas operatives — los mas cemunes en 
use hoy en dia son la diagonal (/), empleada en sistemas tipo Unix y deriva- 
dos (incluyendo MacOS X y Android), y la diagonal invertida (\), empleada en 
CP/m y derivados, incluyendo MS-DOS y Windows. 

Diverses sistemas han manejade etres caracteres (per ejemplo, el MacOS 
historico empleaba los dos puntos, : ), y aunque muchas veces los manteman 
ocultos del usuario mediante una interfaz grafica rica, los programadores siem- 
pre tuvieren que manejarles expllcitamente. 

A lo large del presente texto se empleara la diagonal (/) come separader de 
directories. 
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Sistema de archives piano 

Los primeros sistemas de archives limitaban el concepto de directorio a vna 
representacion plana de los archives que lo conformaban, sin ningiin concepto 
de jerarqma de directorios como el que hoy resulta natural a los usuarios. Esto 
se debia, en primer termino, a lo limitado del espacio de ahnacenamiento de 
las primeras computadoras en implementar esta metafora (por lo limitado del 
espacio de almacenamiento, los usuarios no dejaban sus archivos a largo plazo 
en el disco, sino que los tenian ahi meramente mientras los requerian), y en se- 
gujndo termino, a que no se habia aiin desarroUado \m concepto de separacion, 
permisos y privilegios como el que poco despues apareceria. 

En las computadoras personales los sistemas de archivos eran tambien pia- 
nos en un primer momento, pero por otra razon: en los sistemas profesionales ya 
se habia desarrollado el concepto; al aparecer la primer computadora personal 
en 1975, ya existfan incluso las primeras versiones de Unix disenadas para tra- 
bajo en red. La prioridad en los sistemas personales era mantener el codigo del 
sistema operativo simple, mfnimo. Con unidades de disco capaces de mane- 
jar entre 80 y 160 KB, no tenia mucho sentido implementar directorios — si un 
usuario quisiera llevar a cabo una division tematica de su trabajo, lo colocarfa 
en distintos discos flexibles. El sistema operativo CP/M nunca soporto jerarquias 
de directorios, como tampoco lo hizo la primer version de MS-DOS.^ 

El sistema de archivos original de la Apple Macintosh, MPS, estaba cons- 
truido sobre un modelo piano, pero presentando la ilusion de directorios de 
una forma comparable a las etiquetas: eran representados bajo ciertas vistas 
(aimque notoriamente no en los dialogos de abrir y grabar archivos), pero el 
nombre de cada uno de los archivos tenia que ser linico, dado que el direcorio 
al que pertenecia era basicamente solo un atributo del archivo. 

Y contrario a lo que dicta la intuicion, el modelo de directorio piano no 
ha desaparecido: el sistema de almacenamiento en la nube ofrecido por el servi- 
cio Amazon S3 {simple storage service, servicio simple de almacenamiento) maneja 
linicamente objetos (comparable con la definicion de archivos que se ha venido 
manejando) y cubetas (de cierto modo comparables con las unidades o volurne- 
nes), y permite referirse a ujn. objeto o un conjunto de estos basado en filtros 
sobre el total que conforman una cubeta. 

Conforme se desarrollen nuevas interfaces al programador o al usuario, 
probablemente se popularicen mas ofertas como la que hoy hace Amazon S3. 
Al dia de hoy, sin embargo, el esquema jerarqmco sigue, con mucho, siendo el 
dominante. 



'El soporte de jerarqufas de directorios fue introducido apenas en la version 2.0 de dicho sis- 
tema operativo, junto con el soporte a discos duros de 10 MB, acompanando al lanzamiento de la 
IBM PC modelo XT. 
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Directorios de profundidad fija 

Las primeras implementaciones de directorios eran de un solo nivel: el total 
de archivos en un sistema podia estar dividido en directorios, fuera por tipo de 
archivo (separando, por ejemplo, programas de sistema, programas de usua- 
rio y textos del correo), por usuario (facilitando una separacion logica de los 
archivos de un usuario de pertenecientes a los demas usuarios del sistema) 

El directorio raiz (base) se llama en este esquema mfd {master file directory, 
directorio maestro de archivos), y cada ujno de los directorios derivados es ujn. UFD 
{user file directory, directorio de archivos de usuario). 



MFD 




Figura 6.5: Directorio simple, litnitado a un solo nivel de profundidad. 



Este esquema resuelve el problema principal del nombre global linico: an- 
tes de los directorios, cada usuario tenia que cuidar que los nombres de sus 
archivos fueran unicos en el sistema, y ya teniendo cada uno su propio espa- 
cio, se volvio una tarea mucho mas simple. La desventaja es que, si el sistema 
restringe a cada usuario a escribir en su ufd, se vuelve fundamentaLmente im- 
posible trabajar en algiin proyecto conjunto: no puede haber un directorio que 
este tanto dentro de u s r 1 como de u s r 2 , y los usuarios encontraran mas dif icil 
llevar un proyecto conjunto. 

Directorios estructurados en arbol 

El siguiente paso natural para este esquema es permitir una jerarquta ilimi- 
tada: en vez de exigir que haya una capa de directorios, se le puede dar la vuelta 
al argumento, y permitir que cada directorio pueda contener a otros archivos 
o directorios a niveles arbitrarios. Esto permite que cada usuario (y que el ad- 
ministrador del sistema) estructure su informacion siguiendo criterios logicos 
y piense en el espacio de almacenamiento como un espacio a largo plazo. 

Junto con esta estructura nacen las rutas de busqueda {search path): tanto los 
programas como las bibliotecas de sistema ahora pueden estar en cualquier 
lugar del sistema de archivos. Al definirle al sistema una ruta de busqueda, el 
usuario operador puede desentenderse del lugar exacto en el que esta deter- 
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<raiz> 




Figura 6.6: Directorio estucturado en drbol. 



minado programa — el sistema se encargara de buscar en todos los directorios 
mencionados los programas o bibliotecas que este requiera.^" 

El directorio como un grafo dirigido 

Si bien pareceria que muchos de los sistemas de archivos empleados hoy en 
dfa pueden modelarse suficientemente con un arbol, donde hay un solo nodo 
raiz, y donde cada uno de los nodos tiene un solo nodo padre, la semantica que 
ofrecen es en realidad un superconjunto estricto de esta: la de un grafo dirigido. 

En un grafo dirigido como el presentado en la figiira 6.7, \m mismo nodo 
puede tener varios directorios padre, permitiendo, por ejemplo, que un directo- 
rio de trabajo comun sea parte del directorio personal de dos usuarios. Esto es, 
el mismo objeto esta presente en mas de un punto del arbol. 

Un sistema de archivos puede permitir la organizacion como un grafo diri- 
gido, aunque es comiin que la interfaz que presenta al usuario^^ se restrinja a 
un grafo dirigido actclico: las ligas multiples son permitidas, siempre y cuando 
no generen un ciclo. 

La semantica de los sistemas Unix implementa directorios como grafos di- 
rigidos por medio de dos mecanismos: 

Liga o enlace dure La entrada de un archivo en un directorio Unix es la rela- 
cion entre la ruta del archivo y el numero de i-nodo en el sistema de archi- 
vos. Si a partir de \m archivo en cualqmer punto del arbol se crea ima 

^"La ruta de busqueda refleja la organizaci6n del sistema de archivos en el contexto de la insta- 
lacion especifica. Es comun que la ruta de busqueda de un usuario estandar en Unix sea similar 
a /usr/local/bin : /usr/bin : /bin : ~/bin — esto significa que cualquier comando que sea 
presentado es buscado, en el orden indicado, en los cuatro directorios presentados (separados por 
el caracter : , la notacion ~ indica el directorio personal del usuario active). En Windows, es comiin 
encontrar la ruta debiisqueda c : \WINDOWS\system32 ; c: \WINDOWS 

^^Esta simplificaci6n es simplemente ima abstraccion, y contiene una pequena mentlra, que serS 
desmentida en breve. 

^^El signiflcado y la estructura de im i-nodo se abordan en el capitulo 7. 



244 



CAPITULO 6. ORGANIZACION DE ARCHIVOS 




Figura 6.7: Directorio como un grafo dirigido adclico: el directorio proyecto estd 
tanto en el directorio /home/usrl como en el directorio /home/usr2. 



liga dura a el, esta es sencillamente otra entrada en el directorio apuntan- 
do al mismo i-nodo. Ambas entradas, pues, son el mismo archivo — ^no 
hay uno maestro y iino dependiente. 

En iin sistema Unix, este mecanismo tiene solo dos restricciones: 

1 . Solo se pueden hacer ligas duras dentro del mismo volumen. 

2. No pueden hacerse ligas duras a directorios, solo a archivos.^^ 

Liga o enlace simbolico Es un archivo especial, que meramente indica a donde 
apunta. El encargado de seguir este archivo a su destino (esto es, de resol- 
ver la liga simbolica) es el sistema operative mismo; un proceso no tiene 
que hacer nada especial para segiiir la liga. 

Una liga simbolica puede apuntar a directorios, incluso creando ciclos, o 
a archivos en otros voWmenes. 

Cuando se crea una liga simbolica, la liga y el archivo son dos entida- 
des distintas. Si bien cualquier proceso que abra al archivo destino estara 
trabajando con la misma entidad, en caso de que este sea renombrado o 
eliminado, la liga quedara rota (esto es, apuiitara a una ubicacion inexis- 
tente). 

Si bien estos dos tipos de liga son validos tambien en los sistemas Win- 



^^Formalmente, puede haberlas, pero s61o el administrador puede crearlas; en la secci6n 6.3.2 se 
cubre la raz6n de esta restricci6n al hablar de recorrer los directorios. 
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dows, en dichos sistemas sigue siendo mas comun emplear los accesos direc- 
tos. Se denomina asi a un archive (identificado por su extension, .Ink), prin- 
cipalmente creado para poder apuntar a los archivos desde el escritorio y los 
menues; si un proceso solicita al sistema abrir el acceso directo, no obtendra al 
archivo destino, sino al acceso directo mismo. 

Si bien el API de Win32 ofrece las funciones necesarias para emplear las 
ligas, tanto duras como simbolicas, estas no estan reflejadas desde la interfaz 
usuario del sistema — y son sistemas donde el usuario promedio no emplea 
una interfaz programador, sino que una interfaz grafica. Las ligas, pues, no son 
mas empleadas por cuestion cultural: en sus comuiudades de usuarios, nujnca 
fueron frecuentes, por lo cual se mantienen como conceptos empleados solo 
por los usuarios avanzados. 

Ya con el conocimiento de las ligas, y reelaborando la figura 6.7 con mayor 
apego a la realidad: en los sistemas operativos (tanto Unix como Windows), 
todo directorio tiene dos entradas especiales: los directorios . y . . , que apa- 
recen tan pronto como el directorio es creado, y resultan fundamentals para 
mantener la navegabilidad del arbol. 



Figura 6.8: Directorio como un grafo dirigido, mostrando los enlaces ocultos al direc- 
torio actual . y al directorio padre . . 

Como se puede ver en la figura 6.8, en todos los directorios, . es una liga 
dujra al mismo directorio, y . . es ima liga al directorio padre (de nivel jerar- 
quico inmediatamente superior). Claro esta, como solo puede haber vna liga 
. . , un directorio enlazado desde dos lugares distintos solo apunta hacia \mo 

^^tJnicamente en aquellos que emplean el sistema de archivos que introdujo Windows NT, el 
NTFS, no en los que utiUzan algima de las variantes de FAT. 
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de ellos con su enlace . .; en este caso, el directorio comiin proyecto esta 
dentro del directorio /home/usr2. La figura representa la liga simbolica desde 
/home/ usrl como una llnea punteada. 

Hay una excepcion a esta regla: el directorio ralz. En este caso, tanto . como 
. . apuntan al mismo directorio. 

Esta es la razon por la cual no se puede tomar rigurosamente un arbol de 
archivos como un grafo dirigido aciclico, ni en Windows ni en Unix: tanto las 
entradas . (al apuntar al mismo directorio donde estan contenidas) como las 
entradas . . (al apuntar al directorio padre) crean ciclos. 

6.3.2. Operaciones con directorios 

Al igual que los archivos, los directorios tienen una semantica basica de ac- 
ceso. Estos resultan tambien tipos de datos abstractos con algunas operaciones 
definidas. Muchas de las operaciones que pueden realizarse con los directorios 
son analogas a las empleadas para los archivos. Las operaciones basicas a 
presentar son: 

Abrir y cerrar Como en el caso de los archivos un programa que requiera tra- 
bajar con un directorio debera abrirlo para hacerlo, y cerrarlo cuando ya 
no lo requiera. Para esto, en C, se emplean las funciones opendir ( ) y 
closedir { ) . Estas funciones trabajan asociadas a unflujo de directorio 
{directory stream), que funciona de forma analoga a un descriptor de ar- 
chivo. 

Listado de archivos Para mostrar los archivos que conforman a un directo- 
rio, una vez que se abrio el directorio se abre, el programa lee (con 
readdir ( ) ) cada una de sus entradas. Cada uno de los resultados es 
ima estructura dirent {directory entry, esto es, entrada de directorio), que 
contiene su nombre en d_name, un apuntador a su i-nodo en d_ino, y 
algimos datos adicionales del archivo en cuestion. 

Para presentar al usuario la lista de archivos que conforman un directo- 
rio, podrla hacerse: 

1 #include <stdio.h> 

2 #inclucie <dirent.h> 

3 #include <sys/types .h> 

4 

5 int main(int argc, char *argv[]) { 

6 struct dirent *archivo; 

7 DIR *dir; 

S if (argc != 2) { 

9 printf ("Indique el directorio a mostrar\n" ) ; 



^^De hecho, en muchos sistemas de archivos los directorios son meramente archivos de tipo es- 
pecial, que son presentados al usuario de forma distinta. En la seccion 7.1.4 se presenta un ejemplo. 
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10 return 1; 

11 } 

12 dir = opendir (argv [1] ) ; 

13 while ((archive = readdir (dir) ) != 0) { 

14 printf ( "%s\t" , archivo->d_name) ; 

15 } 

16 printf ("\n") ; 

17 closedir (dir) ; 

18 } 



Al igual que en al hablar de archives se puede reposicionar (seek ( ) ) al 
descriptor de archive, para rebobinar el descriptor del directorio al prrnci- 
pio del listado se emplea rewinddir ( ) . 

Buscar un elemento Si bien en el transcurso del use del sistema operative re- 
sulta una operacion frecuente que el usuario solicite el listado de archi- 
ves dentro de un directorio, es mucho mas frecuente buscar a un archivo 
en particular. La llamada f open ( ) antes descrita efectiia una busqueda 
similar a la presentada en el ejemplo de codigo anterior, claro esta, dete- 
niendose cuando encuentra al archivo en cuestion. 

Crear, eliminar o renombrar un elemento Si bien estas operaciones se llevan 
a cabo sobre el directorio, son invocadas por medio de la semantica 
orientada a archives: un archivo es creado con f open ( ) , eliminado con 
remove ( ) , y renombrado con rename ( ) . 

Recorriendo los directories 

Es frecuente tener que aplicar una operacion a todos los archives dentro 
de cierto directorio, por ejemplo, para agrupar un directorio complete en un 
archivo comprimido, o para copiar todos sus contenidos a otro medio; procesar 
todas las entradas de un directorio, incluyendo las de sus subdirectories, se 
denemrna recorrer el directorio (en ingles, directory traversal). 

Si se trabaja sobre un sistema de archives plane, la operacion de recerride 
complete puede realizarse con un pregrama tan simple come el presentado en 
la seccion anterior 

Al hablar de un sistema de profundidad fija, e incluse de un directorio es- 
tructurade en arbel, la logica se cemplica levemente, dado que para recorrer 
el directorio es necesario revisar, entrada por entrada, si esta es a su vez un 
directorio (y en caso de que asl sea, entrar y procesar a cada uno de sus ele- 
mentos). Hasta aqul, sin embargo, se puede recorrer el directorio sin mantener 
estructuras adicionales en memoria representando el estado. 

Sin embargo, al considerar a los grafos dirigidos, se vuelve indispensable 
mantener en memoria la informacion de todos los nodos que ya han sido to- 
cados — en caso contrario, al encontrar ciclo (incluso si este es creado por me- 
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canismos como las ligas simholicas), se corre el peligro de entrar en un bucle 
infinito. 




Figura 6.9: Directorio basado en grafo dirigido que incluye ciclos. 



Para recorrer al directorio ilustrado como ejemplo en la figiira 6.9, no bas- 
tarla tomar nota de las rutas de los archives conforme son recorridas — cada 
vez que los sean procesados, su ruta sera distinta. Al intentar respaldar el di- 
rectorio /home/ jose/proyecto, por ejemplo, el recorrido resiiltante podria 
ser: 



■ /home/ jose/proyecto 



■ /home/ jose/proyecto/miembros 



■ /home/ jose/proyecto/miembros/ jose 



■ /home/ jose/proyecto/miembros/ jose/proyect OS 



■ /home/ jose/proyecto/miembros/ jose /proyect OS /miembr OS 



■ . . . Y im etcetera infinito. 



Para resolver esta situacion, los programas que recorren directories en los 
sistemas de archivos reales deben emplear un indexado basado en i-nodo}^ que 
identifica sin ambiguedad a cada uno de los archivos. En el caso presentado, 
si el i-nodo de jose fuera 10 543, al consultar a los miembros de miembros el 
sistema encontrara que su primer entrada apunta al i-nodo 10 543, por lo cual 
la registraria solo como un apimtador a datos ya archivados, y continuaria con 
la segunda entrada del directorio, que apimta a pedro. 



^^Que si bien no ha sido definido alin formalmente, para esta discusidn bastard saber que es un 
nlimero linico por volumen. 
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Otros esquemas de organizacion 

For mas que el uso de sistemas de archivos basados en directories jerarqid- 
cos parece universal y es muy atnpliamente aceptado, hay cada vez mas casos 
de uso que apimtan a que se pueda estar por dar la bienvenida a una nueva 
metafora de organizacion de archivos. 

Hay distintas propuestas, y claro esta, es imposible aiin saber cual direccion 
obtendra el favor del mercado — o, dado que no necesariamente siga habiendo 
\m modelo apto para todos los usos, de que segmento del mercado. 

6.3.3. Montaje de directorios 

Para trabajar con el contenido de uxi sistema de archivos, el sistema opera- 
tive tiene que montarlo: ubicarlo en algiin pimto del arbol de archivos visible al 
sistema y al usuario. 

Es muy comun, especialmente en los entornos derivados de Unix, que un 
sistema operative trabaje con distintos sistemas de archivos al mismo tiempo. 
Esto puede obedecer a varias causas, entre las cuales se encuentran: 

Distintos medios fisicos Si la computadora tiene mas de una unidad de akna- 
cenamiento, el espacio dentro de cada uno de los discos se maneja como 
vm sistema de archivos indepentiente. Esto es especialmente cierto en la 
presencia de imidades removibles (CD, imidades USB, discos duros exter- 
nos, etc.) 

Diferentes usos esperados Como se vera mas adelante, distintos esquemas de 
organizacion (esto es, distintos sistemas de archivos) presentan ventajas 
para diversos patrones de uso. Por ejemplo, tiene sentido que una base 
de datos resida sobre una organizacion distinta a la de los programas 
ejecutables (binaries) del sistema. 

Abstracciones de sistemas no-fisicos El sistema operative puede presentar 
diversas estructuras con una estructura de sistema de archivos. El ejem- 
plo mas claro de esto es el sistema de archivos virtual /proc, presente en 
los sistemas Unix, que permite ver diversos aspectes de los preceses en 
ejecucion (y, en Linux, del sistema en general). Los archivos bajo /proc 
no estan en ningiin disco, pero se presentan como si fueran archivos es- 
tandar. 

Razones administrativas El administrador del sistema puede emplear siste- 
mas de archivos distintos para aislar espacios de usuarios entre si: por 
ejemplo, para evitar que un exceso de mensajes enviados en la bitacora 
(tlpicamente bajo /var/log) saturen al sistema de archivos principal, o 
para determinar patrones de uso maximo por grupos de usuarios. 
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En los sistemas tipo Unix, el mecanismo para montar los archives es el de 
un arbol con puntos de montaje. Esto es, todos los archivos y directorios del sistema 
operative estan estructurados en un unico drbol. Cuando se solicita al sistema 
operativo montar un sistema de archivos en determinado lugar, este se Integra 
al arbol, ocultando todo lo que el directorio en cuestion previamente tuviera.^'' 




Figtira 6.10: Arbol formado del montaje de sdal en la raiz, sda2 como /usr, sdbl 
como /home, y el directorio virtual proc. 



La manera en que esto se presenta en sistemas Windows es muy distinta. 
Ahl, cada uno de los volumenes detectados recibe un identificador de volumen, y 
es montado automaticamente en un sistema de directorio estructurado como 
arbol de un solo nivel representando a los dispositivos del sistema. Este arbol 
es presentado a traves de la rnterfaz grafica (aunque este nombre no significa 
nada para el API del sistema) como Mi Computadora. 

Para especificar la ruta completa a determinado archivo, se inicia con el iden- 
tificador del volumen. De este modo, la especificacion absoluta de un archivo 
es una cadena como VOL : \Dirl\Dir2 \Archivo . ext — el caracter : sepa- 
ra al volumen del arbol del sistema de archivos, y el caracter \ separa uno de 
otro a los directorios. For convencion, si no se especifica la unidad, el sistema 
asumira que se esta haciendo referenda a la unidad actual (a grandes rasgos, la 
liltima unidad en ser utilizada). 

Los identificadores de volumen estan preasignados, muchos de ellos segiin 
un esquema heredado desde la epoca de las primeras PC: los volumenes A y B 
estan reservados para las unidades de disco flexible; C se refiere al disco duro 
de arranque, y las unidades posteriores que va detectando el sistema son D, E, 
F, etcetera. 

Es posible modificar esta nomenclatura y configurar a los discos para estar 

^^Hay implementaciones que exigen que el montaje se realice exclusivamente en directorios va- 
cios; se tienen otras, como UnionFS, que buscan seguir presentando una interfaz de lectura a los 
objetos que existlan en el directorio previo al montaje, pero realizan las escrituras linicamente en 
el sistema ya montado; estas compUcan fuertemente algunos aspectos semanticos, por lo cual re- 
sultan poco comunes. 

^''En realidad, este arbol no solo incluye a los volumenes de almacenamiento, sino que a los 
demas dispositivos del sistema, como los distintos puertos, pero los oculta de la interfaz grafica. 
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en otra ubicacion, pero muchas aplicaciones dependen ya de este comporta- 
miento y configuracion especifica. 




6.4. Control de acceso 



Parte importante de la informacion que se almacena respecto a cada uno de 
los archives, directories u otros objetos son sus permisos de acceso. Estos indi- 
can al sistema que puede hacerse y que no con cada uno de los objetos, posi- 
blemente diferenciando el acceso dependiendo del usuario o clase de usuarios 
de que se trate. 

Hay muchos esquemas de control de acceso; a continuacion se presentan 
tres esquemas, comenzando por el mas simple, y avanzando hacia los mas 
complejos. 
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6.4.1. Sistemas FAT 

El sistema de archives FAT^^ fue disenado a fines de los setenta, y al dfa de 
hoy es muy probablemente el sistema de archives mas ampliamente utilizado 
del mimdo. Su diseno es suficientemente simple para ser inclmdo en dispositi- 
vos muy limitados; esta simplicidad se demostrara al analizar sus principales 
estructuras son analizadas en el capftulo 7. Y por otro lado, con solo modifi- 
caciones relativamente menores a su disefio original, ha logrado extenderse de 
ujn. sistema pensado para voliimenes de 150 KB hasta llegar a las decenas de 
gigabytes. 

En cada una de las entradas del directorio en un sistema fat, el byte niimero 
12 almacena los siguientes atributos: 

Oculto Si esta encendido, el archivo no se debera mostrar al usuario en lista- 
dos de directorio. 

Solo lectura El sistema operative debe evitar toda modificacion al archivo, es- 
to es, rechazar las llamadas al sistema que soliciten esta modificacion. 

Sistema Como se explicara en la secdon 7.7, un sistema de archives fat tiende 
conforme se va utilizando Afragmentar los archives que almacena. La car- 
ga del sistema operative tiene que realizarse empleande codige le mas 
compacto y sencillo posible: sin siquiera tener conocimiento del sistema 
de archives. Este atributo indica que el sistema operative debe cuidar no 
mover ni fragmentar al archive en cuestion. 

Archivado MS-DOS incluia herramientas bastante sencillas para realizar res- 
paldos; estas basaban su eperacion en este atributo: Conforme se realiza- 
ba un respaldo, todos los archives iban siendo marcados como archivados. 
Y cuando un archivo era modificado, el sistema operative retiraba este 
atributo. De esta manera, el siguiente respaldo contendria linicamente 
los archives que habfan side modificados desde el respaldo anterior. 

Estos atributos eran suficientes para las necesidades de un sistema de uso 
personal de hace mas de tres decadas. Sin embargo, y dado que esta reservado 
todo un byte para los atributos, algimos sistemas extendieron los atributos cu- 
briendo distintas necesidades. Estos cuatro atributos son, sin embargo, la base 
del sistema. 

Puede verse que, bajo MS-DOS, no se hace diferencia entre lectura y ejecu- 
cion. Como se presento en la seccion 6.2.4, el sistema MS-DOS basa la identifi- 
caci6n de archivos en su extension. Y, claro, siendo un sistema concebido como 
monousuario, no tiene sentido condicionar la lectura de \m archivo: el sistema 
operative siempre permitira la lectura de cualquier archivo. 



^'Recibe su nombre de las siglas de su estructura fundamental, la Tabla de Asignacion de Archivos, 
o File Allocation Table. 
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6.4.2. Modelo tradicional Unix 

El sistema Unix precede a MS-DOS por una decada. Sin embargo, su concep- 
cion es de origen para un esquema multiusuario, con las provisiones necesarias 
para que cada uno de ellos indique que usuarios pueden o no tenet diferentes 
tipos de acceso a los archivos. 

En Unix, cada uno de los usuarios pertenece a uno o mas grupos. Estos gru- 
pos son gestionados por el administrador del sistema. 

Cada objeto en el sistema de archivos describe sus permisos de acceso por 
nueve bits, y con el identificador de su usuario y grupo propietarios. 

Estos bits estan dispuestos en tres grupos de tres; uno para el usuario, uno 
para el grupo, y uno para los otros. Por ultimo, los tres grupos de tres bits in- 
dican si se otorga permiso de lectura, escritura y ejecucion. Estos permisos son 
los mismos que fueron presentados en la seccion 5.5.1, relativos al manejo de 
memoria. 

Estos tres grupos de tres permiten suficiente granularidad en el control de 
acceso para expresar casi cualquier combinacion requerida. 

Por poner un ejemplo, si los usuarios jose, pedro y teresa estan co- 
laborando en el desarroUo de un sistema de facturacion, pueden solicitar 
al administrador del sistema la creacion de un grupo, factura. Una vez 
creado el sistema, y suponiendo que el desarroUo se efectua en el directorio 
/usr/local/f actura/, podrian tener los sigmentes archivos: 

$ Is -la /usr/local/f actura/ 
drwxrwxr-x root factura 4096 . 
drwxr-xr-x root root 40 96 .. 

-rw-r root factura 12055 compilacion.log 

-rwxrwxr-x pedro factura 114500 factura 
-rw-rw-r — teresa factura 23505 factura. c 
-rw-rw-r — jose factura 1855 factura. h 

-rw-rw teresa factura 36504 f actura. o 

-rw-rw teresa factura 40420 lineamientos.txt 

-rw-rw-r — pedro factura 3505 Makefile 

Este ejemplo muestra que cada archivo puede pertenecer a otro de los 
miembros del grupo.^" Para el ejemplo aqui mostrado, el usuario propietario 
es menos importante que el grupo al que pertenece. 

La ejecucion solo esta permitida, para los miembros del grupo factura, 
en el archivo factura: los demas archivos son ya sea el codigo fuente que se 
emplea para generar dicho archivo ejecutable, o la informacion de desarroUo y 
compilacion. 

Respecto al acceso del resto de los usuarios (esto es, aquellos no perte- 
necientes al grupo factura), todos tienen permiso de lectura sobre todos 



^"Los archives pertenecen al usuario que los cre6, a menos que su propiedad sea cedida por el 
administrador a otro usuario. 
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los archives a excepcion del archive intermedio de compilacion, f actura . o, 
el documento de diseno, lineamientos . txt, y la bitacora de compilacion, 
compilacion . log 

Este ejemplo muestra los directorios . y . . , que fueron presentados en la 
seccion 6.3.1. Para los directorios, se emplea el mismo sistema de permisos; el 
permiso de escritura indica quien puede crear o eliminar archivos dentro de el, 
el de lectura indica que usuarios pueden averiguar la lista de archivos conteni- 
dos en dicho directorio, y el de ejecucion indica que usuarios pueden entrar al 
directorio. En este caso, todos los usuarios pueden listar (leer) y ejecutar (en- 
trar) al directorio, pero linicamente el administrador root y los miembros del 
grupo f actura pueden modificar los archivos que contiene. 

Claro esta, el directorio . . (que apunta de vuelta al directorio padre, 
/usr/local/) es del sistema, y permite solo la lectura y ejecucion a todos 
los usuarios (incluyendo al grupo f actura). 

En este punto, cabe recordar que, en un sistema Unix, los dispositivos del 
sistema asl como varios objetos virtuales (como las tuberias de comunicacion 
entre procesos) son representados en el sistema de archivos. Esto significa que, 
por medio de estos permisos, el administrador del sistema puede indicar que 
usuarios pueden tener permisos de lectura o modificacion sobre los diferentes 
componentes hardware del sistema. 

El esquema de persmisos de Unix presenta algunas caracteristicas adicio- 
nales, como los bits SUID/SGID o los atributos extendidos que presentan ciertas 
implementaciones; se sugiere al lector interesado referirse a las pdginas de ma- 
nual de Linux para los comandos chmod y chattr, respectivamente. 

6.4.3. Listas de control de acceso 

Una de las desventajas del modelo tradicional de usuarios Unix es que re- 
quiere de la intervencion del administrador del sistema para cada nuevo pro- 
yecto: el administrador del sistema tuvo que crear al grupo f actura antes 
de que pudiera realizarse ningiin trabajo de forma colaborativa. Ademas, en- 
contrar la representacion justa para indicar un conjunto especifico de permisos 
puede ser complicado. Dado que un archivo no puede pertenecer a mas de 
un grupo, puede hacerse necesario crear conjuntos de grupos adicionales que 
intersectan aspectos especificos: una salida muy poco elegante. 

Varios sistemas operativos, incluyendo particularmente a las versiones de 
Windows derivadas del NT, han agregado listas de control de acceso (o acl, del 
ingles. Access Control Lists): cada uno de los archivos tiene asociada una lista 
donde se indican los permisos particulares que tendra sobre este cada usuario o 
grupo particular. La figura 6.12 muestra un ejemplo de la definicion del control 
de acceso a un archivo en el sistema operativo Windows 7. 

Si bien el modelo de listas de control de acceso brinda un control mucho 
mas fino sobre cada uno de los archivos, no esta exento de desventajas: en pri- 
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General Seguridad | Detales | Versiones anteriores | 
Nombre de ob|eto: C:\Users\Public\Pictures\Sample PicturesM 
Nombres de grupos o usuarios 



rn SYSTEM 


•y», BATCH 




Administradores (vif f\AdministradoresJ 




A*, INTERACTIVE 
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^(LSERViao 




Pata cambiaf los pefmisos, 

haga die en Editar. 

Permisos de SYSTEM Petmitii 


Editaf... 1 
Denegar 



Control total 
Modilicar 

Lectuiav e|ecuci6n 

Lectuia 

Escritura 

Permisos especiates 



Para especificar permisos especiales o Opciones avanzadas j 

cor^tiguiaciones avanzadas^ haga clic 1 

eri Opciones avanzadas 

Qbtener mas informacion acerca de control v permisos de acceso 



Aceptar | Cancelar | 



Figura 6.12: Lista de control de acceso a un archivo en Windows 7: En esta vista, 
muestra que el gmpo SYSTEM tiene permiso para todo tipo de acceso a excepcion 
del definido por Permisos especiales. 



mer termino, todos los permisos particulares que tenga un archivo tienen que 
almacenarse junto con su i-nodo. Dado que su longitud es variable, se repre- 
sentan como una estructura adicional adjunta a los datos del archivo, y esto se 
traduce en un tiempo de acceso ligeramente mayor. 

En segundo termino, resulta mas dificil presentar un listado compacto y 
completo de los permisos para todos los archivos en determinado directorio. 
Realizar una evaluacion al vuelo de los controles de acceso se vuelve mas com- 
plejo para el administrador. 

En tercer lugar, este esquema da lugar a ambigiiedades, cuya politica de 
resolucion debe establecerse a priori. Por ejemplo, si un usuario pertenece a 
dos grupos distintos, uno de ellos con aprobacion expUcita para la escritura a 
cierto archivo, y otro con denegacion expUcita para la escritura al mismo, debe 
haber una politica global para resolver si el permiso sera otorgado o rechazado. 
Estas politicas no siempre resultan faciles de comprender por los usuarios del 
sistema. 
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6.5. Sistemas de archives remotes 

Uno de los principales y primeros usos que se dio a la comiinicacion en red 

fue el de compartir archives entre computadoras independientes. En un princi- 
pio, esto se realizaba de forma expltcita, con transferencias manuales mediante 
de programas dedicados a ello, como seria hoy en dia el ftp. 

Por otro lado, desde mediados de los ochenta, es posible realizar estas trans- 
ferencias de forma impltcita y automdtica, empleando sistemas de archivos sobre la 
red (o lo que es lo mismo, sistemas de archivos remotos). Estos se presentan como 
caso particular de la abstraccion de sistemas no-flsicos que fueron mencionados 
en la seccion anterior: si bien el sistema operativo no tiene acceso directo a los 
archivos y directorios que le solicitara el usuario, por medio de los modulos de 
red, sabe como obtenerlos y presentarlos como sifueran locales. 

Al hablar de sistemas de archivos en red, casi siempre se hara siguiendo un 
modelo cliente-servidor. Estos terminos no se refieren a las prestaciones relativas 
de una computadora, sino al papel que esta desempena dentro de cada conexion, 
esto es, se designa como cliente a la computadora que solicita un servicio, y 
como servidor a la que lo provee; es frecuente que dos computadoras sean tanto 
servidor como cliente la una de la otra en distintos servicios. 

6.5.1. Network File System (NFS) 

El Sistema de Archivos en Red {Network File System, mejor conocido como NFS) 
fue creado por Sun Microsystems, y desde 1984 forma parte de su sistema ope- 
rativo — resulto una implementacion tan exitosa que a los pocos afios formaba 
parte de todos los sistemas tipo Unix. 

Esta construido sobre el mecanismo RFC {remote procedure call, llamada a pro- 
cedimientos remotos), un mecanismo de mensajes y manejo basico de sesion que 
actiia como una capa superior a TCP /if, incluyendo facilidades de descubri- 
miento de recursos y abstraccion. RFC puede ser comparado con protocolos como 
DCE/rfc de OSF, DCOM de Microsoft, y hoy en dia, SOAP y XML-RFC. Estos 
mecanismos permiten al programador delegar en un servicio el manejo de las 
conexiones de red, particularmente (en el caso particular aquf descrito) la per- 
sistencia de sesiones en caso de desconexion, y limitar su atencion a una cone- 
xion virtual establecida. 

La motivacion de origen para la creacion de NFS fue presentar una solucion 
que aprovechara el hardware ya comiin en dicha epoca, y que centralizara la 
administracion: ofrecer las facilidades para contar con redes donde hubiera un 
servidor de archivos, y donde las estaciones de trabajo tuvieran linicamente una 
instalacion basica,-^^ y el entomo de usuario completo estuviera disponible en 
cualquiera de las estaciones. 

^^Incluso manejando estaciones de trabajo diskless, esto es, computadoras sin disco duro, cuyo 
sistema de arranque tiene la capacidad de soUcitar al servidor le envie incluso el nticleo del sistema 
operativo que ejecutard. 
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El sistema de archives que ofrece sobre la red NFS cumple con la semantica 
Unix completa — para emplear un sistema remoto, basta montarlo'^^ y usarlo 
como si fuera local. El manejo de permisos, usuarios, e incluso las ligas duras 
y simbolicas se manejajn. exactamente como se haria localmente. 

El NFS viaja sobre im protocolo muy ligero; no implementa cifrado ni veri- 
ficaciones adicionales. Al dia de hoy, es uno de los mejores mecanismos para 
el envlo de grandes cantidades de informacion — pero siempre en redes que 
sean completamente confiables. 

Ahora, NFS se presenta como uno de los componentes de una solucion com- 
pleta. Dado que se espera que la informacion de usuarios y permisos sea consis- 
tente en todos los clientes; Sun ofrecia tambien un esquema llamado Yellow Pa- 
ges (posteriormente renombrado a NIS, Network Information System) para com- 
partir la informacion de autenticacion y listas de usuarios. 

La desventaja, en entomos sin NiS, es que los permisos se manejan segun el 
identificador numerico del usuario. Si en diferentes sistemas el mismo usuario 
tiene distintos identificadores, los permisos no coincidiran. Es mas, dado que 
el control de acceso principal es linicamente por direccion IP, para tener acce- 
so irrestricto a los archives de otros usuarios en NFS basta con tener control 
pleno de una computadora cualquiera en la red para poder asumir o usurpar la 
identidad de cualqmer otro usuario. 

Por ultimo, para garantizar que las escrituras a archivos se Uevaran a cabo 
cuando eran solicitadas (en contraposicion a asumir exito y continuar), todas 
las escrituras en un principio sobre NFS eran manejadas de forma smcrona, esto 
es, tras grabar un archivo, el cliente no continuaba con la ejecucion hasta no te- 
ner confirmacion por parte del servidor de que los datos estaban ya guardados 
en disco. Esto, si bien asegura que el usuario recibira retroalimentacion con- 
fiable respecto a la operacion que realize, ocasiona demoras que muchas veces 
son percibidas como excesivas. 

Versiones posteriores del protocolo mejoraron sobre los puntos debiles aqul 
mencionados. Al dla de hoy, casi 30 anos despues de su presentacion, NFS es 
aiin \m sistema de archivos en red muy ampliamente empleado. 

6.5.2. Common Internet File System (CIFS) 

El eqmvalente a NFS en los entornos donde predominan los sistemas Win- 
dows es el protocolo CIFS {Common Internet File System, Sistema de Archivos 
Comun para Internet). Aparece en los sistemas primarios de Microsoft alrede- 
dor de 1990,^^ originalmente bajo el nombre SMB {server message block, bloque de 
mensaje del servidor). 

^^Para montar un sistema remoto, se emplea un comando como mount 
archivos . unam.mx: /ext/home /home, con lo cual el directorio /ext/home ubicado en 
el servidor archivos .unam.mx aparecerS montado como directorio /home local. 

^^El desarroUo de SMB naci6 como LAN Manager, originalmente para OS/2. 
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Las primeras implementaciones estaban basadas en el protocolo NBF, fre- 
cuentemente conocido como NetBEUI, un protocolo no rateable disenado para 
redes pequenas y entomos sencillos de oficina. A partir de Windows 2000 se ha 
reimplementado completamente para operar sobre TCP/IP. Es a partir de este 
momento que se le comienza a denominar CIFS, aunque el nombre SMB sigue 
siendo ampliamente utilizado.^* 

El sistema CIFS se ajusta mucho mas a la semantica de los sistemas fre- 
cuentemente encontrados en las PC, MS-DOS y Windows, aunque dado el lapso 
transcurrido desde su introduccion y el volumen de cambios en su mercado 
objetivo, ha pasado por varios cambios fimdamentales, que al dia de hoy com- 
plican su uso. 

Para tener acceso a un volumen compartido por SMB se introdujo el co- 
mando NET;-^^ basta indicar desde la linea de comando a DOS o Windows NET 
USE W: \\servidor\directorio para que el recurso compartido bajo el 
nombre directorio dentro del equipo conocido como servidor aparezca 
en el arbol Mi PC, y el usuario pueda emplear sus contenidos como si fuera un 
sistema de archivos local, con \m volumen asignado de w : . 

Cuando LAN Manager fue introduddo al mercado, los sistemas Microsoft 
no manejaban aiin el concepto de usuarios, por lo que la unica medida de se- 
guridad que implementaba SMB era el manejo de hasta dos contrasenas por 
directorio compartido: con una, el usuario obtenla acceso de solo lectura, y 
con la otra, de lectura y escritura. Tras la aparicion de Windows NT, se agrego 
un esquema de identificacion por usuario /contrasena, que posibilita el otorga- 
miento de permisos con una granularidad mucho menor.^^ 

El protocolo empleado por SMB fue pensado originalmente para una red pe- 
quena, con hasta un par de decenas de equipos. La mayor parte de los paquetes 
eran enviados en modo de difusion (broadcast), por lo que era facil llegar a la 
saturacion, y no habia un esquema centralizado de resolucion de nombres, por 
lo que era frecuente no encontrar a determinado equipo. 

Los cambios que CIFS presenta a lo largo de los anos son muy profundos. 
Las primeras implementaciones presentan fuertes problemas de confiabilidad, 
rendimiento y segujidad, ademas de estar planteadas para su uso en un so- 
lo tipo de sistema operativo; al dia de hoy, todos estos puntos han mejorado 
fuertemente. En sistemas Unix, la principal implementacion. Samba, fue crea- 
da haciendo ingenieria inversa sobre el protocolo; a lo largo de los anos, se 
ha convertido en un esquema tan robusto que es hoy por hoy tomado como 
implementacion refrencia. 



^''Es debido a este nombre que la implementacibn de CIFS para sistemas Unix, Samba, fue llama- 
do de esta manera. 

^^Este comando es empleado en MS-DOS, pero esta tambi^n disponible en Windows, y al dia de 
hoy es una de las principales herramientas para administrar usuarios. 

^*Esto significa, que puede controlarse el acceso permitido mis flnamente, tanto a nivel archivo 
como usuario individuales. 
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6.5.3. Sistemas de archives distribuidos: Andrew File System 

Los dos ejemplos de sistema de archives en red presentados hasta ahora 
comparten una vision tradidonal del modelo cliente-servidor: al ver el comando 
que inidaliza una conexion, e incluso a ver la informacion que guarda el niicleo 
del cliente respecto a cualqmera de los archives, resulta claro cual es el servidor 
para cada uno de ellos. 

Andrew File System, o AFS, desarrolaldo en la Carnegie Mellon University^^ 
y pubUcado en 1989, plantea presentar xm verdadero sistema de archivos distri- 
buido, en el cual los recursos compartidos no tengan que estar en un servidor en 
particular, sino que un conjunto de equipos se reparian la carga (esto es, ag- 
nosticismo a la ubicacion). AFS busca tambien una fdcil escalabilidad, la capacidad 
de agregar tanto espacio de almacenamiento como equipos con papeles de ser- 
vidor. AFS permite inclusive migrar completamente un volumen mientras esta 
siendo empleado de forma transparente. 

Ante la complejidad e inestabilidad adicional que presentan con tanta fre- 
cuencia las redes grandes^^ (y lo hacian mucho mas hace 30 anos): AFS debe 
operar tan confiablemente como sea posible, incluso sin la certeza de que la red 
opera correctamente. 

La autenticacion en AFS se basa fuertemente sobre el modelo de tickets y 
credenciales de Kerberos,^'^ pero se aleja sensiblemente de la semantica de ope- 
racion de archivos que hasta ahora se han presentado. Muchos eventos, ope- 
raciones y estados van ligados al momenta en el tiempo en que se presentan, 
mediante un modelo de consistencia debil {weak consistency model). Muy a grandes 
rasgos, esto significa que: 

■ Cuando se abre un archivo, este se copia complete al cliente. Todas las 
lecturas y escrituras (a diferencia de los esquemas tradicionales, en que 
estas son enviadas al servidor lo antes posible y de forma sfncrona) se diri- 
gen unicamente a la copia local. 

■ Al cerrar el archivo, este se copia de vuelta al servidor de origen, el cual se 
compromete a notificar a los clientes si un archivo abierto fue modificado 
(esto es, a hacer una llamada o callback). Los clientes pueden entonces in- 
tentar incorporar los cambios a su version de trabajo, o continuar con la 
copia ya obtenida — es de esperarse que si un segundo cliente realiza algu- 
na modificacion, incorpore los cambios hechos por el primero, pero esta 
responsabilidad se deja a la implementacion del programa en cuestion. 

Esto significa en pocas palabras que los cambios a un archivo abierto por 
un usuario no son visibles a los demas de inmediato; solo una vez que se cierra 

^^Como parte del Proyecto Andrew, denominado asi por el nombre de los fundadores de esta 
universidad: Andrew Carnegie y Andrew Mellon. 

^*E1 uso tipico de AFS se planteaba para organizaciones grandes, del orden de decenas de miles 
de estaciones. 

^'Un sistema de autenticaci6n y autorizaci6n centralizado para entomos corporativos. 
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un archivo, los cambios hechos a este son puestos a disposicion de las sesiones 
abiertas actuales, y solo son enviados como version actual a las sesiones abiertas 
posteriormente. 

Con este cambio semantico, debe quedar claro que AFS no busca ser un sis- 
tema para todo uso ni un reemplazo universal de los sistemas de archivos loca- 
les, en contraposicion de los sistemas de archivos centralizados. AFS no plantea 
en ningiin momento una operacion diskless. Bajo el esquema aqul descrito, las 
lecturas y escrituras resultan baratas, porque se realizan exclusivamente sobre 
el cache local, pero abrir y cerrar un archivo puede ser muy caro, porque debe 
transferirse el archivo completo. 

Hay aplicaciones que verdaderamente sufririan si tuvieran que implemen- 
tarse sobre un sistema de archivos distribuido, por ejemplo, si una base de 
datos se distribuyera sobre AFS, la carencia de mecanismos de bloqueo sobre 
secciones del archivo, y el requisito de operar sobre archivos completos harian 
impracticable compartir un archivo de uso intensivo y aleatorio. 

6.6. Ejercicios 

6.6.1. Preguntas de autoevaluacion 

1. Identifique diferentes sistemas de computo (computadoras, telefonos, 
dispositivos moviles, dispositivos de funcion especifica como camaras 
digitales o reproductores de medios, etc.) a los que tiene acceso. ^Como 
identifica cada uno de ellos el tipo de archivos? Jmplementan alguna 
abstraccion ocultando o traduciendo la presentacion de determinados ar- 
chivos de forma transparente al usuario? 

2. Hay diferentes modos en que un programa puede accesar a la informa- 
cion contenida en un archivo; siendo los principales secuencial, aleatorio 
y relativo a mdice. Indique que casos de uso resuelve mejor cada \mo de 
estos modos de acceso. 

3. iQue tipo de optimizacion podria Uevar a cabo el sistema operativo si 
requiriera que todo programa declarara al momento de abrir un archivo 
si va a utilizarlo de forma mayormente secuencial o aleatoria? 

4. De las siguientes afirmaciones, identifique cuales se refieren a ligas duras, 
a ligas simbolicas, y a enlaces directos. Hay una sola respuesta correcta para 
cada afirmacion. 

a) Son dos (o mas) entradas en el directorio apuntando al mismo i- 
nodo. 

b) Es un archivo normal e independiente en el sistema de archivos, que 
podria ser abierto directamente por los programas. 



6.6. EJERCICIOS 



261 



c) Pueden apuntar a directories, incluso creando ciclos. 

d) Su tipo de archive en el directorio esta indicado por la extension 
. LNK. 

e) El sistema operativo resuelve directamente todas las operaciones como 
sifueran al archivo referido. 

/) No pueden referirse a archivos en sistemas de archivos distintos del 

propio. 

g) Pueden existir en un sistema de archivos tipo FAT. 

h) Si un usuario elitnina cualquiera de las referencias a un archivo em- 
pleando este esquema, el archivo sigue existiendo en las demas. 

5. Cuando se habla acerca de los sistemas de archivos remotos o en red, 
^que significa la semdntica de manejo de errores? Presente un ejemplo de 
como se refleja una distinta semantica entre un sistema de archivos local 
y uno en red. 

6. Suponga que hay un archivo f ileO en un sistema de archivos con se- 
mantica tipo Unix. Explique que ocurre en cada situacion (con su inodo, 
con sus sectores de contenido, entradas de directorio, etcetera): 

■ Copiado: cp fileO filel 

■ Ligadurailn fileO filel 

■ Liga simbolica: In -s fileO filel 

■ Eliminacion: rm f ileO 

7. La estructura i-nodo tiene, en casi todos los sistemas de archivos, un cam- 
po de conteo de ligas. Explique que es. ^Que operaciones llevan a que se 
modifique, que ocurre si llega a cero? 



6.6.2. Temas de investigacion sugeridos 

Sistemas de archivos distribuidos En este capitulo se abordaron tres sistemas 
de archivos remotos, de los cuales solo el tiltitno puede verse como un 
sistema de archivos distribuido: Bajo AFS, los datos aknacenados no estan 
en una unica computadora. Pero AFS tiene ya muchos anos de haber sido 
desarrollado, por lo cual su diseno no considero muchos de los aspectos 
de las redes de datos globales actuales. 

En los liltimos anos se han presentado varias propuestas de sistemas de 
archivos verdaderamente distribuidos, aptos para la implementacion de 
nubes de datos y de ima distribucion geografica de la informacion; algu- 
nos ejemplos de estos sistemas de archivos son GlusterFS (desarrollado 
por RedHat), S3 (de Amazon), GoogleFS (de Google), Windows Distribu- 
ted File System (de Microsoft), y CEFH (tambien de RedHat). 
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iQue semantica ofrecen estos sistemas de archives, como se comparan 
con la nativa de las diferentes plataformas, como se opera en caso de des- 
conexion o falla, parcial o total, que caracteristicas hacen a estos sistemas 
especialmentehuenos para su uso distribuido, habria algima desventaja de 
emplear esos sistemas en un entorno de red local? 

6.6.3. Lecturas relacionadas 

■ File System Interface: Functions for manipulating files 

https : / /www . gnu . org/software/libc/manual/htinl_node /File- System- Inter face . 

html 

The GNU C Library manual (Free Software Foundation) 

■ Disks from the Perspective of a File System 

http : / /queue . acm. org/detail . cfm?id=2367378 
Marshall Kirk McKusick (2012); ACM Queue 

• Traduccion al espanol: Los discos desde la perspectiva de un sistema de 

archives 

http : // cyanezf dz . me/post /los- discos -desde- la-perspectiva- de-un- si sterna- de-; 
Cesar Yanez (2013). 

■ File-system development with stackable layers 

https : / /dl . acm. org/citation. cfm?id=17 4 513.174616 

Heidemann y Popek (1994); ACM Transactions on Computer Systems 

■ Serverless network file systems 

https : / /dl . acm. org/citation . cfm?doid=225535 .225537 
Thomas E. Anderson et. al. (1996); ACM Transactions on Computer Sys- 
tems 

■ OpenPlanets Results Evaluation Framework 

http : / /data . openplanetsf oundation . org/ref / 

David Tarrant (2012). Muestra la evolucion a lo largo de los anos de como 
reconocen archivos de tipos conocidos varias herramientas 

■ Finding open files with Isof 

http : / / www . ibm . com/ developerworks/aix/ library/ au- Isof . html) 
Sean A. Walberg (2006); IBM DeveloperWorks 



Capitulo 7 

Sistemas de archives 



7.1. Plasmando la estructura en el dispositive 

A lo largo del capitulo 6 se abordaron los elementos del sistema de archi- 
vos tal como son presentados al usuario final, sin entrar en detalles respecto 
a como organiza toda esta informacion el sistema operativo en un dispositivo 
persistente — ^mencionamos algunas estructuras base, pero dejandolas explici- 
tamente pendientes de definicion. En este capitulo se trataran las principales 
estructuras y mecanismos empleados para que un sistema de archivos sea ya 
no solamente una estructura formal ideal, sino que una entidad almacenada en 
un dispositivo. 

A lo largo de la historia del computo, el ahnacenamiento no siempre se 

realize en discos (dispositivos giratorios de acceso aleatorio). For varias deca- 
das, los medios principales almacenamiento eran de acceso estrictamente se- 
cuencial (tarjetas perforadas, cintas de papel, cintas magneticas); por mas de 
30 afios, el medio primario de almacenamiento han sido los distintos tipos de 
discos magneticos, y desde hace algunos anos, estamos viendo una migracion a 
almacenamiento de estado sdlido, a dispositivos sin partes moviles que guardan la 
informacion en un tipo particular de memoria (tema que se abordara en la sec- 
cion C.1.2). Volviendo a las categorfas presentadas en la seccion 2.8, los medios 
de acceso secuencial son dispositivos de caracteres, y tanto discos como unidades 
de estado solido son dispositivos de bloques. 

7.1.1. Conceptos para la organizacion 

Los sistemas de archivo estan en general desarrollados pensando en discos, 
y a lo largo de este capitulo, se hara referenda como el disco al medio de al- 
macenamiento persistente en el cual este plasmado el sistema de archivos. En 
el apendice C se tocaran algunos de los aspectos que debemos considerar al 
hablar de sistemas de archivos respaldados en medios distintos a un disco. 
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Mientras tanto, conviene mantener una vision aiin bastante idealizada y 
abstracta: un disco visto desde la perspectiva del sistema operativo sera presen- 
tado a lo largo del presente capitulo^ como iin arreglo muy grande de bloques 
de tamafio fijo, cada uno de ellos diredamente direccionable; esto significa que 
el sistema operativo puede referirse por igual a cualqmera de los bloques del 
disco mediante una direcdon fisica e inambigua dentro del disco entero. Par- 
tiendo de esto, se emplean los siguientes conceptos para almacenar, ubicar o 
recuperar la informacion: 

Particion Una subdivision de un disco, por medio de la cual el administrador 
o usuario del sistema puede definir la forma en que se emplea el espacio 
del disco, segmentandolo segiin haga falta. 

Un disco puede tener varias particiones, y cada ima de ellas puede tener 
im sistema de archivos independiente. 

Volumen Coleccion de bloques inicializados con un sistema de archivos que 
pueden presentarse al usuario como una unidad. Tipicamente un volu- 
men coincide con una particion (pero no siempre es el caso, como se des- 
cribira en las secciones C.2 y C.3). 

El volumen se describe ante el sistema operativo en el bloque de control de 
volumen, tambien conocido como superbloque en Unix, o tabla maestra de 
archivos {master file table) en NTFS. 

Sistema de archivos Esquema de organizacion que sigue un determinado vo- 
lumen. Dependiendo del sistema de archivos elegido, cada uno de los 
componentes aqul presentados ocuparan im distinto lugar en el disco, 
presentando una semantica propia. 

Para poder tener acceso a la informacion aknacenada en determinado 

volumen, el sistema operativo debe tener soporte para el sistema de ar- 
chivos particular en que este este estructurado. 

Directorio rafz La estructuxa que relaciona cada nombre de archivo con su mi- 
meros de i-nodo. Tipicamente solo almacena los archivos que estan en el 
primer nivel jerdrquico del sistema, y los directorios derivados son linica- 
mente referenciados desde este. 

En sistemas de archivos modemos, el directorio normalmente incluye so- 
lo el nombre de cada uno de los archivos y el mimero de i-nodo que lo 
describe, todos los metadatos adicionales estan en los respectivos i-nodos. 

Metadatos Recibe este nombre toda la informacion acerca de \m archivo que no 
es el contenido del archivo mismo. Por ejemplo, el nombre, tamano o tipo 
del archivo, su propietario, el control de acceso, sus fechas de creacion, 
ultimo acceso y modificacion, ubicacion en disco, etcetera. 

^Para vm punto de vista m^s riguroso de c6mo se relaciona el sistema operativo con los discos 
y demds mecanismos de ahnacenamiento, refl^rase al ap6ndice C. 
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I-nodo Del ingles i-node, information node (nodo de informacion); en los siste- 
mas tipo Windows, normaLmente se le denomina bloque de control de archi- 
ve (fcb). Es la estructura en disco que guarda los metadatos de cada iino 
de los archivos, proporcionando un vinculo entre la entrada en el directorio 
y los datos que lo conforman. 

La informacion aLmacenada incluye todos los metadatos relacionados 
con el archivo a excepcidn del nombre (mismo que radica linicamente en 
el directorio): los permisos y propietarios del archivo, sus fechas de crea- 
cion, ultima modificacion y ultimo acceso, y la relacion de bloques que ocu- 
pa en el disco. Mas adelante se abordaran algimos de los esquemas mas 
comujn.es para presentar esta relacion de bloques. 

Esta separacion entre directorio e i-nodo permite a un mismo archivo for- 
mar parte de distintos directorios, como se explico en la seccion 6.3.1. 

Mapa de hits de espacio libre La funcion del bitmap es poder gestionar el es- 
pacio libre del disco. Recuerdese que el disco se presenta asignado por 
bloques, tipicamente de 4 096 bytes — en el bitmap cada bloque se repre- 
senta con tm bit, con lo que aqui se puede encontrar de forma compacta 
el espacio ocupado y disponible, as! como el lugar adecuado para crear 
un nuevo archivo. 

El bitmap para un disco de 100 GB, de esta manera, se puede represen- 
tar en 23 MB C^oie cantidad que puede razonablemente mantener en 
memoria \m sistema de escritorio promedio hoy en dla.^ 

Mas adelante se veran algunas estructuras avanzadas que permiten ma- 
yor eficiencia en este sentido. 

7.1.2. Diferentes sistemas de archivos 

Un sistema operativo puede dar soporte a varios distintos sistemas de ar- 
chivos; ujn. admirustrador de sistemas puede tener muy diferentes razones que 
influyan para elegir cual sistema de archivos empleara para su informacion; 
algunas razones para elegir a imo u otro son que el rendimiento de cada tmo 
puede estar afinado para diferentes patrones de carga, necesidad de emplear un 
dispositivo portatil para intercambiar datos con distintos sistemas, e incluso 
restricciones de hardware.^ 

A lo largo de esta seccion se revisara como los principales conceptos a abor- 
dar se han implementado en distintos sistemas de archivos; se hara referenda 

^Esto explica porque, incluso sin estar trabajando activamente con ningun archivo contenido en 
este, el solo hecho de montar un volumen con gran cantidad de datos obliga al sistema a reservarle 
ima cantidad de memoria. 

^Por ejemplo, los cargadores de arranque en algimas plataformas requieren poder leer el volumen 
donde estd alojada la Imogen del sistema operativo — ^lo cual obliga a que est^ en un sistema de 
archivos nativo a la plataf orma. 
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principalmente a una familia de sistema de archives simple de comprender, 
aunque muestra claramente su edad: el sistema FAT. La razon para elegir al sis- 
tema de archives fat es la simplicidad de sus estructuras, que permiten com- 
prender la organizacion general de la informacion. Donde sea pertinente, se 
mencionara en que puntos principales estiba la diferencia con los principales 
sistemas de la actualidad. 

El sistema FAT fue creado hacia finales de los setenta, y su diseno muestra 
claras evidencias de haber sido concebido para discos flexibles. Sin embargo, 
por medio de varias extensiones que se han presentado con el paso de los afios 
(algimas con compatibilidad hacia atras/ otras no), sigue siendo uno de los 
sistemas mas empleados al dia de hoy, a pesar de que ya no es recomendado 
como sistema prunario por ningun sistema operativo de escritorio. 

Si bien FAT tuvo su mayor difusion con los sistemas operativos de la familia 
MS-DOS, es un sistema de archivos nativo para una gran cantidad de otras pla- 
taformas (muchas de ellas dentro del mercado embebido), lo cual se hace obvio 
al revisar el soporte a atributos extendidos que maneja. 

7.1.3. El volumen 

Lo primero que requiere saber el sistema operativo para poder montar im 
volumen es su estructura general: en primer termino, de que tipo de sistema 
de archivos se trata, y acto seguido, la descripcion basica del mismo: su exten- 
si6n, el tamano de los bloques Idgicos que maneja, si tiene alguna etiqueta que 
describa su funcion ante el usuario, etc. Esta informacion esta contenida en el 
bloque de control de volumen, tambien conocido como superbloque o tabla maestra 
de archivos? 

Tras leer la informacion del superbloque, el sistema operativo determina en 
primer termino si puede proceder — si no sabe como trabajar con el sistema de 
archivos en cuestion, por ejemplo, no puede presentar informacion litil alguna 
al usuario (e incluso arriesgarfa destruirla). 

Se menciono ya que el tamano de bloques (historicamente, 512 bytes; el es- 
tandar Advanced Format en marzo del 2010 introdujo bloques de 4 096 bytes) 
es establecido por el hardware. Es muy comiin que, tanto por razones de efi- 
ciencia como para alcanzar a direccionar mayor espacio, el sistema de archivos 
agrupe a varios bloques flsicos en uno logico. En la seccion 7.1.4 se revisara que 
factores determinan el tamano de bloques en cada sistema de archivos. 

Dado que describir el volumen es la mas fundamental de las operaciones 
a realizar, muchos sistemas de archivos mantienen copias adicionales del super- 
bloque, a veces dispersas a lo largo del sistema de archivos, para poder recu- 
perarlo en caso de que se corrompa. 

■*Se denomina compaiibilidad hacia aims a aquellos cambios que permiten interoperar de forma 
transparente con las versiones anteriores. 

aqul hay que aclarar: este bloque no contiene a los archivos, ni siquiera a las estructuras que 
apuntan hacia ellos, s61o describe al volumen para que pueda ser montado. 
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En el caso de FAT, el volumen indica no solo la generacion del sistema de 
archivos que se esta empleando (FAT12, FAT16 o FAT32, en los tres casos deno- 
minados asi per la cantidad de bits para referenciar a cada iino de los bloques 
logicos o clusters), sino el tamano de los clusters, que puede ir desde los dos y 
hasta los 32 KB. 

Volumenes crudos 

Si bien una de las principales tareas de un sistema operativo es la organiza- 
cion del espacio de aLmacenamiento en sistemas de archivos y su gestion para 
compartirse entre diversos usuarios y procesos, hay algunos casos en que un 
dispositivo orientado a bloques puede ser puesto a disposicion de un proce- 
so en particular para que este lo gestione directamente. Este modo de uso se 
denomina dispositivos crudos o dispositivos en crudo {raw devices). 

Pueden encontrarse dos casos de uso primarios hoy en dia para dispositivos 
orientados a bloques no administrados mediante la abstraccion de los sistemas 
de archivos: 

Espacio de intercambio Como se vio en la seccion 5.7.2, la gestion de la por- 

cion de la memoria virtual que esta en disco es mucho mas eficiente cuan- 
do se hace sin cruzar por la abstraccion del sistema operativo — esto es, 
cuando se hace en un volumen en crudo. Y si bien el gestor de memoria 
virtual es parte innegable del sistema operativo, en un sistema microkernel 
puede estar ejecutandose como proceso de usuario. 

Bases de dates Las bases de datos relacionales pueden incluir volumenes muy 
grandes de datos estrictamente estructurados. Algunos gestores de bases 
de datos, como Oracle, MaxDB o db2, recomiendan a sus usuarios el uso 
de volumenes crudos, para optimizar los accesos a disco sin tener que 
cruzar por tantas capas del sistema operativo. 

La mayor parte de los gestores de bases de datos desde hace varios anos 
no manejan esta modalidad, por la complejidad adicional que supone 
para el administrador del sistema y por lo limitado de la ventaja en ren- 
dimiento que supone hoy en dfa, aunque es indudablemente un tema que 
se presta para discusion e investigacion. 

7.1.4. El directorio y los i-nodos 

El directorio es la estructura que relaciona a los archivos como son presen- 
tados al usuario -identificados por una ruta y un nombre- con las estructuras 
que los describen ante el sistema operativo — los i-nodos. 

A lo largo de la historia de los sistemas de archivos, se han implementado 
muy distintos esquemas de organizacion. Se presenta a continuacion la estruc- 
tura basica de la popiilar familia de sistemas de archivos FAT. 
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El directorio raiz 

Una vez que el sistema de archives esta montado (vease 6.3.3), todas las re- 
ferencias a archives dentro de este deben pasar a traves del directorio. El di- 
rectorio raiz esta siempre en una ubicacion Men conocida dentro del sistema de 
archives — tlpicamente al inicio del voliimen, en los primeros sectores^. Un 
disco flexible tenia 80 pistas (tipicamente denominadas cilindros al hablar de 
discos duros), con lo que, al ubicar al directorio en la pista 40, el tiempo pro- 
medio de movimiento de cabezas para llegar a el se reducla a la mitad. Si todas 
las operaciones de abrir un archivo tienen que pasar por el directorio, esto re- 
sultaba en una mejorla muy significativa. 

El directorio es la estructura que determina el formato que debe seguir el 
nombre de cada uno de los archives y directories: es comun que en un sistema 
modemo, el nombre de un archivo pueda tener hasta 256 caracteres, incluyen- 
do espacios, caracteres intemacionales, etc. Algunos sistemas de archives son 
sensibles a mayusculas, come es el caso de los sistemas natives a Unix (el archi- 
vo e jemplo . txt es distinto de E jemplo . TXT), mientras que otros no lo son, 
come es el caso de NTFS y vfat (e j emplo . txt y E j emplo . TXT son identicos 
ante el sistema operative). 

Todas las versiones de fat siguen para los nombres de archives un esquema 
claramente arcaico: los nombres de archivo pueden medir hasta echo caracte- 
res, con una extension opcional de tres caracteres mas, dando un total de 11. 
El sistema no solo no es sensible a ma5nisculas y minusculas, sino que todos 
los nombres deben guardarse completamente en mayusculas, y permite solo 
ciertos caracteres no alfanumericos. Este sistema de archives no implementa 
la separacion entre directorio e i-nodo, que hoy es la norma, por lo que cada 
una de las entradas en el directorio mide exactamente 32 bytes. Como es de 
esperarse en vin formato que ha vivido tanto tiempo y ha pasado por tantas ge- 
neraciones como FAT, algunos de estos campos han cambiado sustancialmente 
sus significados. La figura 7.1 muestra los campos de una entrada del directorio 
bajo FAT32. 
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Figura 7.1: Formato de la entrada del directorio bajo FAT (Mohammed, 2007). 



*Una excepci6n a esta logica se presento en la decada de los 1980, cuando los disenadores del 
sistema AmigaOS, decidieron ubicar al directorio en el sector central de los voltimenes, para reducir 
a la mitad el tiempo promedio de acceso a la parte mds frecuentemente referida del disco. 
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La extension VFAT fue agregada con el lanzamiento de Windows 95. Esta 
extension permitia que, si bien el nombre real de un archivo seguiria estando 
limitada al formato presentado, pudieran agregarse entradas adicionales al di- 
rectorio utilizando el atributo de etiqueta de volumen de maneras que \m sistema 
MS-DOS debiera ignorar.'' 

Esto presenta una complicacion adicional al hablar del directorio ratz de 
tina unidad: si bien los directories derivados no tienen este lunite, al estar el 
directorio raiz ubicado en una seccion fija del disco, tiene una longitud limite 
maxima: en vn disco flexible (que hasta el dia de hoy, por su baja capacidad, se 
formatea bajo fat12), desde el bloque 20 y hasta el 33, esto es, 14 bloques. Con 
un tamano de sector de 512 bytes, el directorio raiz mide 512 x 14 = 7 168 bytes, 
esto es, ^Jj^ — 224 entradas como maximo. Y si bien esto puede no parecer 
muy limitado, ocupar cuatro entradas por archivo cuando, empleando VFAT, 
se tiene un nombre medianamente largo reduce fuertemente el panorama. 

El problema no resulta tan severo como podria parecer: para FAT32, el di- 
rectorio raiz ya no esta ubicado en un espacio reservado, sino que como parte 
del espacio de datos, por lo cual es extensible en caso de requerirse. 

Los primeros sistemas de archives estaban pensados para unidades de muy 
baja capacidad; por mucho tiempo, las rmplementaciones del directorio eran 
simplemente listas lineales con los archives que estaban alojados en el volu- 
men. En muchos de estos primeros sistemas no se consideraban directories 
jerarquices, sine que presentaban \m linice espacio piano de nembres; cuando 
estos sistemas fueron evolucionando para soportar directories anidados, por 
cempatibilidad hacia atras (y por censideraciones de renduniento que se aber- 
dan a centinuacion) siguieren ahnacenande linicamente al directorio raiz en 
esta posicion privilegiada, manejando a todos los directories que derivaran de 
este como si fueran archives, repartidos por el disco. 

En un sistema que implementa los directories come listas lineales, entre 
mas archives haya, el tiempo que tema casi cualquier eperacion se incrementa 
linealmente (dado que potencialmente se tiene que leer el directorio complete 
para encontrar un archive). Y las listas lineales presentan un segunde proble- 
ma: come reaccienar cuando se llena el espacio que tienen asignade. 

Come ya se presento, fat asigna un espacio fije al directorio raiz, pere los 
subdirectories pueden crecer abritrariamente. Un subdirectorio es basicamente 
una entrada con un tipe especial de archive — si el doceavo byte de una entrada 
de directorio, que indica los atributos del archivo (ver figura 7.1 y cuadre 7.1) 
tiene al bit cuatro activade, la region de dates cerrespendientes a diche archive 
sera interpretada come un subdirectorio. 



'La etiqueta de volumen estaba definida para ser empleada exclusivamente a la cabeza del direc- 
torio, dando una etiqueta global al sistema de archives complete; el signiflcado de una entrada de 
directorio con este atributo hasta antes de la incorporacibn de VFAT no estaba definida. 
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Figtira 7.2: Entradas representando archives con (y sin) nombre largo bajo VFAT. 



La tabla de asignacion de archives 

Queda claro que FAT es un sistema heredado, y que exhibe muchas practicas 
que ya se han abandonado en disefios modemos de sistemas de archives. Se 
vio que dentro de la entrada de directorio de cada archivo esta practicamente 
su i-nodo complete: la informacion de permisos, atributos, fechas de creacion, 
y muy particularmente, el apuntador al cluster de inicio (bytes 26-28, mas los 
20-22 para FAT32). Esto resulta en una de las grandes debilidades de FAT: la 
tendencia a la fragmentacion. 

La familia FAT obtiene su nombre de la tabla de asignacion de archivos (file 
allocation table), que aparece antes del directorio, en los primeros sectores del 
disco. ^ Cada byte de la FAT representa un cluster en el area de datos; cada en- 
trada en el directorio indica, en su campo cluster, cual es el primer cluster que 
conforma al archivo. Ahora bien, conforme se usa un disco, y los archivos cre- 
cen y se eliminan, y van llenando los espacios vaclos que van dejando, FAT va 



^Esta tabla es tan importante que, dependiendo de la version de FAT, se guarda per duplicado, 
o incluso per triplicado. 



7.1. PLASMANDO LA ESTRUCTURA EN EL DISPOSmVO 



271 



Cuadro 7.1: Significado de cada uno de los bits del byte de atributos del archivo en el 
directorio FAT. La semintica que se presenta es la empleada por los sistemas MS- 
DOS y Windows; otros sistemas pueden presentar comportamientos adicionales. 



Bit 


Nombre 


Descripcion 


0 


Solo lectura 


El sistema no permitira que sea modificado. 


1 


Oculto 


No se muestra en listados de directorio. 


2 


Sistema 


El archivo pertenece al sistema y no debe 
moverse de sus dusters (empleado, por 
ejemplo, para los componentes a cargar para 
iniciar al sistema operativo). 


3 


Etiqueta 


Indica el nombre del volumen, no un archivo. 
En VFAT, expresa la continuacion de wx 
nombre largo. 


4 


Subdirectorio 


Los clusters que componen a este archivo 
son interpretados como un subdirectorio, 
no como \m archivo. 


5 


Archivado 


Empleado por algunos sistemas de respaldo 
para indicar si un archivo fue modificado 
desde su ultima copia. 


6 


Dispositivo 


Para uso intemo del sistema operativo, no 
fue adoptado para los archivos. 


7 


Reservado 


Reservado, no debe ser manipulado. 



asignando espacio conforme encuentra nuevos clusters libres, sin cuidar que sea 
espacio continuo. Los apuntadores al siguiente cluster se van marcando en la 
tabla, cluster por cluster, y el ultimo de cada archivo recibe el valor especial 
(dependiendo de la version de fat) OxFFF, OxFFFF o OxFFFFFFFF. 

Ahora bien, si los directorios son sencillamente archivos que reciben un 
tratamiento espedal, estos son tambien susceptibles a la fragmentacion. Dentro 
de un sistema Windows 95 o superior (empleando las extensiones VFAT), con 
directorios anidados a cuatro o cinco niveles como lo establece su jerarquia 
estandar,^ la simple tarea de recorrerlos para encontrar determinado archivo 
puede resultar muy penalizado por la fragmentacion. 

La eliminacion de entradas del directorio 

Solo unos pocos sistemas de archivos guardan sus directorios ordenados 
— si bien esto facilitarla las operaciones mas frecuentes que se realizan so- 
bre ellos (en particular, la biisqueda: cada vez que un directorio es recorrido 



'For ejemplo, C:\Documents and Settings\Usuario\Menu Inicio\Programa 
E jemplo\Programa Ejemplo. Ink 
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hasta encontrar un archive tiene que leerse potencialmente completo), mante- 
nerlo ordenado ante cualquier modificacion resultaria mucho mas caro, dado 
que tendria que reescribirse el directorio completo al crearse o eliminarse un 
archive dentro de este, y lo que es mas importante, mas peligroso, dado que 
aumentaria el tiempo que los datos del directorio estan en im estado incon- 
sistente, aumentando la probabilidad de que ante una interrupcion repentina 
(fallo de sistema, corte electrico, desconexion del dispositive, etc.) se presen- 
tara corrupcion de la informacion llevando a perdida de datos. Al almacenar 
las entradas del directorio sin ordenar, las escrituras que modifican esta crltica 
estructura se mantienen atomicas: un. solo sector de 512 bytes puede almacenar 
16 entradas basicas de fat, de 32 bytes cada una.^" 

Ordenar las entradas del directorio teniendo sus contenidos ya en memoria 
y, en general, diferir las modificaciones al directorio resiilta mucho mas con- 
veniente en el caso general. Esto vale tambien para la eliminacion de archives 
— a centinuacion se abordara la estrategia que sigue FAT. Cabe recordar que 
FAT fue disenado cuando el medio principal de ahnacenamiento era el disco 
flexible, decenas de veces mas lento que el disco duro, y con mucha menor 
confiabilidad. 

Cuando se le solicita a un sistema de archives FAT eliminar un archive, este 
no se berra del directorio, ni su informacion se libera de la tabla de asigna- 
cion de archives, sine que se marca para ser ignorado, reemplazando el primer 
caracter de su nombre per 0xE5. Ni la entrada de directorio, ni la cadena de 
dusters correspondiente en las tablas de asignacion,^^ son eliminadas — solo 
son marcadas como disponibles. El espacio de ahnacenamiento que el archive 
eliminade ecupa debe, entences, ser sumado al espacio libre que tiene el volu- 
men. Es solo cuando se crea im nuevo archive empleande esa misma entrada, 
o cuando etro archive ecupa el espacio fisice que ecupaba el que fue elimina- 
de, que el sistema operative marca realmente come desecupades los clusters en 
la tabla de asignacion. 

Es per esto per lo que desde los primeros dias de las PC hay tantas he- 
rramientas de recuperacion (e des-borramiento, undeletion) de archives: siempre 
que no haya side creade ime nuevo que ecupe la entrada de directorio en cues- 
tion, recuperar un archive es tan simple come velver a penerle el primer carac- 
ter a su nombre. 

Este es un ejemple de un. mecanismo flojo (en centrapesicion de los mecanis- 
mos ansiosos, come los vistos en la seccion 5.7.1). Eliminar un archive requiere 
de un trabaje mmime, mismo que es diferido al memento de reutilizacion de la 
entrada de directorio. 



i^Aunque en el caso de vfat, las diferentes entradas que componen un s61o nombre de archivo 
pueden quedar separadas en diferentes sectores. 

^^Este tema serd abordado en breve, en la secci6n 7.2.4, al hablar de las tablas de asignacidn de 
archivos. 
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7.1.5. Compresion y desduplicacion 

Los archives almacenados en un area dada del disco tienden a presentar 
patrones comunes. Algunas situaciones ejemplo que llevarian a estos patrones 
comunes son: 

■ Dentro del directorio de trabajo de cada uno de los usuarios hay tipica- 
mente archivos creados con los mismos programas, compartiendo enca- 
bezado, estruchura, y ocasionalmente incluso parte importante del conte- 
nido. 

■ Dentro de los directorios de binarios del sistema, habra muchos archivos 
ejecu tables compartiendo el mismo /ormato hinario. 

■ Es muy comun tambien que ujn usuario almacene versiones distintas del 
mismo documento. 

■ Dentro de un mismo dociraiento, es frecuente que el autor repita en nu- 
merosas ocasiones las palabras que describen sus conceptos principales. 

Conforme las computadoras aumentaron su poder de computo, desde fina- 
les de los ochenta se presentaron varios mecanismos que permitlan aprovechar 
las regularidades en los datos almacenados en el disco para comprimir el es- 
pacio utilizable en un mismo medio. La compresion tlpicamente se hace por 
medio de mecanismos estimativos derivados del analisis del contenido/'^ que 
tienen como resultado vin nivel variable de compresion: con tipos de contenido 
altamente regulares (como podria ser texto, codigo fuente, o audio e imagenes 
en crudo), un volumen puede aLmacenar frecuentemente mucho mas de 200% 
de su espacio real. 

Con contenido poco predecible o con muy baja redundancia (como la ma- 
yor parte de formatos de imagenes o audio, que incluyen ya ima fase de com- 
presion, o empleando cualquier esquema de cifrado) la compresion no ayuda, 
y si reduce el rendimiento global del sistema en que es empleada. 

Compresion de volumen completo 

El primer sistema de archivos que se popularize fue Stacker, comercializado 
a partir de 1990 por Stac Electronics. Stacker operaba bajo MS-DOS, creando un 
dispositivo de bloques virtual alojado en ujn disco estandar.^'^ Varias implemen- 
taciones posteriores de esta misma epoca se basaron en este mismo principio. 

^^Uno de los algoritmos mas frecuentemente utilizados y faciles de entender es la Codificacion 
Huffman; este y la familia de algoritmos Lempel-Ziv sirven de base para practicamente la totalidad 
de las implementaciones. 

^^Esto significa que, al solicitarle la creacion de una unidad comprimida de 30 MB dentro del 
volumen C (disco duro primario), 6sta aparecerla disponible como im volumen adicional. El nuevo 
voWmen requerla de la carga de un controlador especial para ser montado por el sistema operativo. 
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Ahora, sumando la variabilidad derivada del enfoque probabilistico al uso 
del espacio con el ubicarse como una compresion orientada al volumen entero, 
resulta natural encontrar una de las dificultades resultantes del uso de estas he- 
rramientas: dado que el sistema operativo estructura las operaciones de lectura 
y escritura por bloques de dimensiones regulares (por ejemplo, el tamano tipi- 
co de sector hardware de 512 bytes), al poder estos traducirse a mas o menos 
bloques reales tras pasar por \ma capa de compresion, es posible que el siste- 
ma de archivos tenga que reacomodar constantemente la informacion al crecer 
alguno de los bloques previos. Conforme mayor era el tiempo de uso de una 
imidad comprimida por Stacker, se notaba mas degradaci6n en su rendimiento. 

Ademas, dado que bajo este esquema se empleaba el sistema de archivos 
estandar, las tablas de directorio y asignacion de espacio resultaban tambien 
comprimidas. Estas tablas, como ya se ha expuesto, contienen la informacion 
fundamental del sistema de archivos; al comprimirlas y reescribirlas constan- 
temente, la probabilidad de que resulten danadas en alguna falla (electrica o 
logica) aumenta. Y si bien los discos comprimidos por Stacker y otras herra- 
mientas fueron populares, principalmente durante la primera mitad de los no- 
venta, conforme aumento la capacidad de los discos duros fue declinando su 
utilizacion. 

Compresion archivo por archivo 

Dado el exito del que gozo Stacker en sus primeros anos, Microsoft anun- 
cio como parte de las caracteristicas de la version 6.0 de MS-DOS (publicada 
en 1993) que incluiria DoubleSpace, una tecnologia muy similar a la de Stac- 
ker. Microsoft incluyo en sus sistemas operativos el soporte para DoubleSpace 
por siete anos, cubriendo las ultimas versiones de MS-DOS y las de Windows 
95, 98 y Millenium, pero como ya se vio, la compresion de volumen completo 
presentaba importantes desventajas. 

Para el entonces nuevo sistemas de archivos NTFS, Microsoft decidio incluir 
vma caracteristica distinta, mas segura y mas modular: mantener el sistema de 
archivos funcionando de forma normal, sin compresion, y habilitar la compre- 
sion archivo por archivo de forma transparente al usuario. 

Este esquema permite al administrador del sistema elegir, por archivos o 
carpetas, que areas del sistema de archivos desea almacenar comprimidas; esta 
caracteristica viene como parte de todos los sistemas operativos Windows a 
partir de la version XP, liberada en el ano 2003. 

Si bien la compresion transparente a nivel archivo se muestra mucho mas 
atractiva que la de volumen completo, no es una panacea y es frecuente encon- 
trar en foros en Imea la recomendacion de deshabilitarla. En primer termino, 
comprimir im archivo implica que un cambio pequeno puede tener im efecto 
mucho mayor: modificar un bloque puede implicar que el tamano final de los 
datos cambie, lo cual se traduciria a la reescritura del archivo desde ese pimto 
en adelante; esto podria mitigarse insertando espacios para preservar el espa- 
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cio ya ocupado, pero agrega complejidad al proceso (y abona en contra de la 
compresion). Los archivos comprimidos son ademas mucho mas sensibles a la 
corrupcion de datos, particularmente en casos de fallo de sistema o de ener- 
gia: dado que un cambio menor puede resultar en la necesidad de reescribir 
al archivo completo, la ventana de tiempo para que se produzca un fallo se 
incrementa. 

En archivos estructurados para permitir el acceso aleatorio, como podrian 
ser las tablas de bases de datos, la compresion implicaria que los registros no 
estaran ya alineados al tamafio que el programa gestor espera, lo cual acarreara 
necesariamente tma penalizacion en el rendimiento y en la confiabilidad. 

For otro lado, los formatos nativos en que se expresan los datos que tipica- 
mente ocupan mas espacio en el aLmacenamiento de los usuarios finales impli- 
can ya un alto grado de compresion: los archivos de fotograflas, audio o video 
estan codificados empleando diversos esquemas de compresion aptos para sus 
particularidades. Y comprimir un archivo que de suyo esta ya comprimido no 
solo no reporta ningun beneficio, sino que resulta en desperdicio de trabajo por 
el esfuerzo invertido en descomprimirlo cada vez que es empleado. 

La compresion transparente, archivo por archivo, tiene innegables ventajas, 
sin embargo, por las desventajas que unplica, no puede tomarse como el modo 
de operacion por omision. 

Desduplicacion 

Hay una estrategia fundamentalmente distinta para optimizar el uso del 
espacio de almacenamiento, logrando muy altos niveles de sobreuso: guardar 
solo una copia de cada cosa. 

Desde fines de los ochenta se han planteado sistemas unplementando dis- 
tintos tipos de desduplicacion, aunque su efectividad era muy limitada y, por 
tanto, su nivel de adopcion se mantuvo muy reducido hasta recientemente. 

El que se retomara la desduplicacion se debe en buena medida a la consoli- 
dacion de servidores ante la adopcion a gran escala de mecanismos de virtuali- 
zacion (veanse apendice B y en particular la seccion B.5). Dado que un mismo 
servidor puede estar alojando a decenas o centenas de mdquinas virtuales, mu- 
chas de ellas con el mismo sistema operativo y programas base, los mismos 
archivos se repiten muchas veces; si el sistema de archivos puede determinar 
que cierto archivo o bloque esta ya almacenado, podria guardar solamente una 
copia. 

La principal diferencia entre la desduplicacion y las ligas duras menciona- 
das en la seccion 6.3.1 es que, en caso de que cualquiera de estos archivos (o 
bloques) sea modificado, el sistema de archivos tomara el espacio necesario 
para representar estos cambios y evitara que esto afecte a los demas archivos. 
Ademas, si dos archivos inicialmente distintos se hacen iguales, se liberara el 
espacio empleado por vino de ellos de forma automatica. 
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Para identificar que datos estan duplicados, el mecanismo mas utilizado es 
calcular el hash criptogrdfico de los datos^^; este mecanismo permite una bus- 
queda rapida y confiable de coincidencias, ya sea por archive o por bloque. 

La desduplicacion puede realizarse en Imea ofuera de Imea — esto es, anali- 
zar los datos buscando duplicidades al momento que estos Uegan al sistema, o, 
dado que es una tarea intensiva tanto en uso de procesador como de entrada/ - 
salida, realizarla como una tarea posterior de mantenimiento, en mv momento 
de menor ocupacion del sistema. 

Desduplicar a nivel archivo es mucho mas ligero para el sistema que hacerlo 
a ndvel bloque, pero hacerlo a nivel bloque lleva tlpicamente a \ma optrmiza- 
cion del uso de espacio mucho mayor. 

Al dia de hoy, el principal sistema de archivos que implementa desduplica- 
cion es ZFS,^^ desarroUado por Sun Microsystems (hoy Oracle). En Linux, esta 
caracteristica forma parte de BTRFS, aunque no ha alcanzado los niveles de es- 
tabilidad como para recomendarse para su uso en entomos de produccion. 

En Windows, esta funcionalidad se conoce como single instance storage (al- 
macenamiento de instancia linica). Esta caracteristica aparedo, implementada en 
espacio de usuario y operando a nivel de archivo, como una de las caracte- 
risticas del servidor de correo Exchange Server entre los anos 2000 y 2010. A 
partir de Windows Server 2003, la fimcionalidad de desduplicacion existe para 
directamente para NTFS, pero su uso es poco frecuente. 

El uso de desduplicacion, particularmente cuando se efectiia por bloques, 
tiene un alto costo en memoria: para mantener buenos niveles de rendimiento, 
la tabla que relaciona el hash de datos con el sector en el cual esta almacena- 
do debe mantenerse en memoria. En el caso de la implementacion de ZFS en 
FreeBSD, la documentacion sugiere dedicar 5 GB de memoria por cada TB de 
almacenamiento (0.5% de la capacidad total). 

7.1.6. Sistemas de archivos virtuales 

Los sistemas de archivos nacieron para facilitar el uso de dispositivos de 
almacenamiento para la informacion que debe persistir a largo plazo. Sin em- 
bargo, dado que la abstraccion para su uso resulta tan natural para representar 
todo tipo de informacion, desde la decada de los ochenta aparecieron diversas 
implementaciones de discos RAM: programas disenados para tomar un espacio 
de memoria y darle la semantica de vm disco, permitiendo manipular su con- 
tenido como si fuera un disco cualquiera. Esto es, presenta almacenamiento 
volatil, pero de muy alta velocidad. 

Estos esquemas gozaron de relativa popularidad a lo largo de los ochenta 
y noventa; fue, sin embargo, con la popiilarizacion de los sistemas que imple- 

^''Por ejemplo, empleando el algoritmo SHA-256, el cual brinda ima probabilidad de colision de 
1 en 2^, suficientemente confiable para que la perdida de datos sea mucho menos probable que 
la falla del disco. 

^^Las caracteristicas bdsicas de ZFS serdn presentadas en la secci6n C.3.2. 
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mentan memoria virtual que este esquema se volvio verdaderamente popular. 
En los sistemas Linux modemos, la norma es el uso de sistemas de archivos 
virtuales para el espacio de almacenamiento temporal /tmp, e incluso otros 
espacios tradicionalmente persistentes (como el directorio con los archivos de 
dispositivos, /dev) se han convertido en virtuales. 

Una ventana al nucleo 

En jujnio 1984, en el congreso de desarrolladores de sistemas Unix del grupo 
USENIX, T. J. Killian presento el artfciilo "/Processes as files/". Killian imple- 
mento un sistema de archivos virtual para ser montado en el directorio /proc 
del sistema que, en vez de representar un mapa de bloques, presentaba una 
ventana a la lista de procesos en ejecucion en el sistema. El uso de /proc fue 
incorporado a practicamente todos los sistemas tipo Unix. 

Esta idea ha avanzado y madurado, y al dia de hoy es una herramienta 
ftindamental para la administracion de sistemas. Si bien la propuesta original 
de Killian estaba encaminada principalmente a facilitar la implementacion de 
depuradores presentando el espacio de memoria de los procesos, /proc es 
hoy en dia una suerte de ventana a estructuras intemas del sistema: ujn. arbol 
de directorios con una gran cantidad de archivos por medio de los cuales se 
puede monitorear el estado del sistema (memoria libre, numero de procesos, 
consumo de procesador, etc.), e incluso modificar la configuracion del sistema 
en ejecucion. 

Por ejemplo, en Linux, leer de /proc/sys/vm/swappiness dara, por 
omision, un valor de 60. Escribir el valor 100 a este archivo tendra por resul- 
tado inmediato que el sistema sea mas agresivo con la paginacion de memoria 
virtual (vease la seccion 5.7) de lo que normaLmente seria. Por otro lado, escri- 
bir el valor uno tendra por efecto que el sistema operativo realice la paginacion 
solo si no tiene otra alternativa. Un valor de cero tendra como efecto el des- 
habilitar la paginacion por completo. Este archivo, al igual que todos los que 
conforman /proc, se presenta ante los procesos en ejecucion como un archivo 
de tipo normal — la particularidad radica en el sistema de archivos en que se 
ubica. 

Claro esta, por mas que parezca una simple lectura de un archivo, el leer o 
modificar un valor dentro de /proc cruza tambien por una serie de Uamadas al 
sistema; el que la configuracion de la memoria virtual este disponible mediante 
algo que parece ser un archivo (sin serlo) es precisamente un caso de abstraccion 
hacia una interfaz consistente y conocida. 

7.2. Esquemas de asignacion de espacio 

Hasta este punto, la presentacion de la entrada de directorio se ha limitado a 
indicar que esta tiene un apimtador al lugar donde inicia el espacio empleado 
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por el archive. No se ha detallado en como se implementa la asignacion y ad- 
ministracion de dicho espacio. En esta seccion se hara un breve repaso de los 
tres principales mecanismos, para despues explicar como es la implementacion 
de FAT, abordando sus principales virtudes y debilidades. 



7.2.1. Asignacion contigua 

Los primeros sistemas de archivos en disco empleaban un esquema de asig- 
nacion contigua. Para implementar un sistema de archivos de este tipo, no harla 
falta contar con una tabia de asignacion de archivos: bastarla con la informacion 
que forma parte del directorio de FAT — la extension del archivo y la direccion 
de su primer cluster. 



8 B 











1 1 



Directorio 



0x30 + 6 
0x36 + 4 
0x3A + 17 
0x4B + 9 
0x5C + 26 



Figura 7.3: Asignacion contigua de archivos: directorio con inicio y longitud. 



La principal ventaja de este mecanismo de asignacion, claro esta, es la sim- 
plicidad de su implementacion. Brinda ademas la mejor velocidad de trans- 
ferencia del archivo, dado que al estar cada uno de los archivos en espacio 
contiguo en el disco, el movimiento de cabezas se mantiene al mmimo. Sin 
embargo, este mecanismo se vuelve sumamente inconveniente en medios que 
soporten lectura y escritura: es muy sensible a \a fragmentacion externa; si un ar- 
chivo requiere crecer, debe ser movido mtegramente a un bloque mas grande 
(lo cual toma demasiado tiempo), y el espacio que libera un archivo en caso 
de reducirse su necesidad de espacio queda atrapado entre bloques asignados. 
Podemos tener mucho mas espacio disponible que el que podamos asignar a 
un nuevo archivo. 

Los esquemas de asignacion contigua se emplean hoy en dla principalmen- 
te en sistemas de archivo de solo lectura, por ejemplo, lo emplea el sistema 
principal que utilizan los CD-ROM, lSO-9660, pensado para aprovechar al ma- 
ximo un espacio que, una vez grabado, solo podra abrirse en modo de solo 
lectura. Esto explica porque, a diferencia de lo que ocurre en cualquier otro 
medio de almacenamiento, al quemar un CD-ROM es necesario preparar prime- 
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ro una imagen en la que los archives ocupen sus posiciones definitivas, y esta 
imagen debe grabarse en el disco en una sola operacion. 

7.2.2. Asignacion ligada 

Un enfoque completamente distinto seria el de asignacion ligada. Este esque- 
ma brinda mucho mayor flexibilidad al usuario, sacrificando la simplicidad y 
la velocidad: cada entrada en el directorio apunta a un primer grupo de sectores 
(o cluster), y este contiene un apuntador que indica cual es el siguiente. 

Para hacer esto, hay dos mecanismos: el primero, reservar wx espacio al 
final de cada cluster para guardar el apuntador y, el segundo, crear una tabla 
independiente, que guarde unicamente los apuntadores. 

En el primer caso, si se manejan clusters de 2 048 bytes, y se reservan los cua- 
tro bytes (32 bits) finales de cada uno, el resultado seria de gran incomodidad 
a los programadores, ya que, frecuentemente, buscan alinear sus operaciones 
con las fronteras de las estructuras subyacentes, para optimizar los accesos (por 
ejemplo, evitar que un solo registro de base de datos requiera ser lefdo de dos 
distintos bloques en disco). El programador tendrfa que disenar sus estructuras 
para ajustarse a la poco ortodoxa cantidad de 2 044 bytes. 

Y mas alia de esta inconveniencia, guardar los apuntadores al final de cada 
cluster hace mucho mas lento el manejo de todos los archives: al no tener en 
una sola ubicacion la relacion de clusters que conforman un archivo, todas las 
transferencias se convierten en secuenciales: para llegar directamente a determi- 
nado bloque del archivo, habra que pasar por todos los bloques previos para 
encontrar su ubicacion. 

Particularmente por este segundo punto es mucho mas comiin el empleo 
de una tabla de asignacion de archivos — y precisamente asf es como opera FAT 
(de hecho, esta tabla es la que le da su nombre). La tabla de asignacion es un 
mapa de los clusters, representando a cada uno por el espacio necesario para 
guardar un apimtador. 

La principal ventaja del empleo de asignacion ligada es que desaparece la 
fragmentacion interna}^ Al ya no requerir la pre-asignacion de un espacio conti- 
guo, cada uno de los archivos puede crecer o reducirse segiin sea necesario. 

Ahora, la asignacion ligada no solo resulta mas lenta que la contigua, sino 
que presenta ima mayor sobrecarga administrativa: el espacio desperdiciado para 
almacenar los apuntadores tipicamente es cercano a 1% del disponible en el 
medio. 

Este esquema tambien presenta fragilidad de metadatos: si alguno de los 
apuntadores se pierde o corrompe, lleva a que se pierda el archivo completo 

^^Con fragmentacion interna se hace aqui referenda al concepto presentado en la seccion 5.4.1. El 
fenomeno generalmente conocido como fragmentacion se refiere a la necesidad de compactacion; es 
muy distinto, y si se presenta bajo este esquema: cada archivo se separa en pequenos^fl^rnenfos 
que pueden terminar esparcidos por todo el disco, afectando fuertemente en el renditniento del 
sistema. 
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Figura 7.4: Asignacion ligada de archivos: directorio con apuntador solo al primer 
cluster. 



desde ese punto y hasta su final (y abre la puerta a la corrupcion de otro ar- 
chive, si el apuntador queda apuntando hacia un bloque empleado por este; el 
tema de fallos y recuperacion bajo estos esquemas es abordado en la seccion 
7.3). 

Hay dos mecanismos de mitigacion para este problema: el empleado por 
los sistemas FAT es guardar una (o, bajo FAT12, dos) copias adicionales de la 
tabla de asignacion, entre las cuales el sistema puede verificar que se manten- 
gan consistentes y buscar corregirlas en caso contrario. Por otro lado, puede 
manejarse una estructura de lista doblemente ligada (en vez de una lista ligada 
sencilla) en que cada elemento apunte tanto al siguiente como al anterior, con 
lo cual, en caso de detectarse una inconsistencia en la informacion, esta pueda 
ser recorrida de atrds hacia adelante para confirmar los datos correctos. En ambos 
casos, sin embargo, la sobrecarga administrativa se duplica. 

7.2.3. Asignacion indexada 

El tercer modelo es la asignacion indexada, el mecanismo empleado por casi 
todos los sistemas de archivos modemos. En este esquema, se crea una estruc- 
tura intermedia entre el directorio y los datos, unica para cada archivo: el i-nodo 
(o nodo de informacion). Cada uno guarda los metadatos y la lista de bloques del 
archivo, reduciendo la probabilidad de que se presente la corrupcion de apunta- 
dores mencionada en la seccion anterior. 

La sobrecarga administrativa bajo este esquema potencialmente es mucho 
mayor: al asignar el i-nodo, este se crea ocupando como mmimo un cluster 
completo. En el caso de un archivo pequeno, que quepa en un solo cluster, esto 
representa un desperdicio de 100% de espacio (un cluster para el i-nodo y otro 
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Director'io indices 




Figura 7.5: Asignacion indexada de archives: directorio con apuntador al i-nodo 
(ejemplificado con un i-nodo de tamaflo extremadamente ineficiente). 



para los datos); para archives mas grandes, la sobrecarga relativa disminuye, 
pero se mantiene siempre superior a la de la asignacion ligada. 

Un esquema de asignacion indexada brinda una mayor eficiencia de cache 
que la asignacion ligada: si bien en dicho caso es comun guardar copia de la 
tabla de asignacion en memoria para mayor agilidad, con la asignacion inde- 
xada bastara hacer cache solo de la informacion importante, esto es, linicamente 
de los archivos que se emplean en un momento dado. El mapa de asignacion 
para los archivos y directorios que no hayan sido empleados recientemente no 
requeriran estar en memoria. 

Claro esta, mientras que en los esquemas anteriores la tabla central de asig- 
nacion de archivos puede emplearse directamente como el bitmap del volumen, 
en los sistemas de archivos de asignacion indexada se vuelve necesario contar 
con un bitmap independiente — pero al solo requerir representar si cada cluster 
esta vacio u ocupado (y ya no apuntar al siguiente), resulta de mucho menor 
tamano. 

Ahora, ^que pasa cuando la lista de clusters de un archivo no cabe en un 
i-nodo? Este ejemplo se ilustra en el tercer archivo de la figura 7.6: en este caso, 
cada i-nodo puede guardar unicamente tres apuntadores.^^ Al tener un archivo 
con cuatro clusters, se hace necesario extender al i-nodo con una lista adicional. 
La implementacion mas comun de este mecanismo es que, dependiendo del 



^^Algunos sistemas de archivos, como Reiser, BTRFS o UFS, presentan esquemas de asignacion 
sub-cluster. Estos denominan colas (tails) a los archivos muy pequenos, y pueden ubicarlos ya sea 
dentro de su mismo i-nodo o compartiendo un mismo cluster con im desplazamiento dentro de este. 
Esta practica no ha sido adoptada por sistemas de archivos de uso mayoritario por su complejidad 
relativa. 

^^Esto resulta un limite demasiado bajo, y fue elegido meramente para ilustrar el presente punto. 
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Metadatos 
Permisos | Usuario | Grupo 
Moras 



Creacibn Modificaci6n Acceso 




Figura 7.6: Estructura tipica de un i-nodo en Unix, mostrando ademds el raimero 
de accesos a disco necesarios para Uegar a cada cluster (con s61o tres cluster por 
lista). 

tamano del archivo, se empleen apuntadores con los niveles de indireccion que 
vayan haciendo falta. 

iQue tan grande seria el archivo maximo direccionable bajo este esquema 
y unicamente tres indirecciones? Suponiendo magnitudes tipicas hoy en dia 
(clusters de 4 KB y direcciones de 32 bits), en un cluster vaclo caben 128 apunta- 
dores {^-^)- Si los metadatos ocupan 224 bytes en el i-nodo, dejando espacio 
para 100 apimtadores: 

■ Un archivo de hasta (100 — 3) x 4 KB = 388 KB puede ser referido por 
completo directamente en el i-nodo, y es necesario un solo acceso a disco 
para obtener su lista de clusters. 

■ Un archivo de hasta (100 - 3 + 128) x 4 KB = 900 KB puede representarse 
con el bloque de indireccion senciUa, y obtener su lista de clusters significa 
dos accesos a disco adicionales. 
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■ Con el bloque de doble indireccion, puede hacerse referenda a archives 

mucho mas grandes: 

(100 - 3 + 128 + (128 X 128)) x 4 KB = 66 436 KB « 65 MB 

Sin embargo, a estas alturas comienza a llamar la atencion otro impor- 
tante ptmto: para acceder a estos 65 MB, es necesario realizar hasta 131 
accesos a disco. A partir de este punto, resulta importante que el sistema 
operative asigne clusters cercanos para los metadatos (y, de ser posible, 
para los datos), pues la diferencia en tiempo de acceso puede ser muy 
grande. 

■ Empleando triple indireccion, se puede llegar hasta: 

(100 - 3 + 128 + (128 X 128) + (128 x 128 x 128)) x 2 KB = 8 455 044 * 
kb* « 8 GB 

Esto es ya mas de lo que puede representarse en un sistema de 32 bits. 
La cantidad de bloques a leerse, sin embargo, para encontrar todos los 
clusters significarian hasta 16 516 accesos a disco (en el peor de los casos). 

7.2.4. Las tablas en FAT 

Volviendo al caso que se presenta como ejemplo, para el sistema de archives 
FAT, cada entrada del directorio apunta al primer cluster que ocupa cada uno 
de los archives, y se emplea un esquema de asignacion ligada. El directorio 
tiene tambien un campo indicando la longitud total del archive, pere este no es 
empleado para leer la informacion, sine para poderla presentar mas agilmente 
al usuario (y para que el sistema operative sepa donde indicar^zn de archivo al 
leer el ultimo cluster que cempene a determinade archive). 

La estructura fundamental de este sistema de archives es la tabla de asig- 
nacion de archives (file allocation table) — tante que de ella tema su nembre 

FAT. 

Cada entrada de la FAT mide lo que la longitud cerrespendiente a su version 
(12, 16 e 32 bits), y puede tener cualqmera de los valeres descrites en el cuadre 
7.2. 

Cuadro 7.2: Valores especiales que puede almacenar FAT; cualquier otro valor indica 
la direcci6n del siguiente cluster que forma parte del archivo al cual pertenece el 
registro en cuestion. 

FAT12 FAT16 FAT32 Significado 

0x000 0x0000 0x0 0000000 Disponible, puede ser asignado 

0xFF7 0xFFF7 OxFFFFFFF? C/Mster daftado, no debe utilizarse 

OxFFF OxFFFF OxFFFFFFFF Ultimo c/wsfer de un archive 
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Llama la atencion que haya un valor especial para indicar que un cluster tie- 
ne sectores dafiados. Esto remite de vuelta al momento historico de la creacion 
de la familia FAT: siendo el medio predominante de almacenamiento el disco 
flexible, los errores en la superficie eran mucho mas frecuentes de lo que lo son 
hoy en dla. 

Una caracteristica que puede llamar la atencion de FAT es que parecerla 
permitir la fragmentacion de archivos por diseno: dado que el descriptor de cada 
duster debe apuntar al siguiente, puede asumirse que el caso comun es que los 
dusters no ocuparan contiguos en el disco. Claro esta, la tabla puede apuntar 
a varios dusters adyacentes, pero el sistema de archivos mismo no hace nada 
para que asl sea. 
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FAT ID 


1 


Indicacion de fin de cadena 




Clusters vacfos 




El directorlo raiz cabe en un solo cluster 




Primer cadena (un solo cluster: 0003) 




Segunda cadena (12 clusters: 0008 a 0013) 




Tercera cadena (16 clusters: 0014 a 0021) 







Figura 7.7: Ejemplo de entradas en la tabla de asignacion de archivos en FAT32. 



En la seccion 7.1.4, al presentar el formato del directorio de FAT, se men- 
ciono que los subdirectorios son en realidad archivos de un tipo especial: ima 
suerte de archivos estructurados (vease la seccion 6.2.5), gestionados por el sis- 
tema operativo. Lo linico que distingue a un directorio de un archivo normal 
es que, en la entrada que lo describe en su directorio padre, el doceavo byte de 
la entrada (que indica los atributos del archivo, veanse la figura 7.1 y el cuadro 
7.1) tiene activado el bit cuatro. 

Un directorio es almacenado en disco exactamente como cualquier otro ar- 
chivo. Si se le asigna unicamente un cluster, y el tamano del cluster es pequeno 
(2 KB), podra almacenar solo 64 entradas (^^^) y cada cluster adicional le dara 
64 entradas mas. Y dado que es tratado tal cual si fuera un archivo normal, 
estara sujeto tambien a la fragmentacion: conforme se agreguen entradas al 
directorio, este crecera. Llegado el momento, requerira clusters adicionales. Y 
si un directorio termina disperso por todo el disco, resultara -como cualquier 
otro archivo- mas lento leerlo y trabajar con el. Siempre que se abra un archivo 
dentro de un directorio grande, o que se le recorra para abrir algun archivo en 
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un subdirectorio suyo, el sistema tendra que buscar todos sus fragmentos a lo 
largo del disco. 

Ante estos dos aspectos, no puede perderse de vista la edad que tiene el sis- 
tema FAT. Otros sistemas de archives mas modernos han resuelto este proble- 
ma mediante los grupos de asignacion: los directories del sistema son esparcidos 
a lo largo del volumen, y se intenta ubicar los archivos cerca de los directorios 
desde donde son referidos.^^ Esto tiene como consecuenda que los archivos 
que presentan cercania temdtica (que pertenecen al mismo usuario o proyecto, 
o que por alguna razon estan en la misma parte de la jerarquia del sistema) 
quedan ubicados en disco cerca xmos de otros (y cerca de sus directorios). Y 
dado que es probable que sean empleados aproximadamente al mismo tiem- 
po, esto reduce las distancias que recorreran las cabezas. Ademas, al esparcir 
los archivos, se distribuye tambien mejor el espacio libre, por lo cual el efecto 
de los cambios de tamano de un archive en le relative a la fragmentacion se 
limita a los que forman parte del mismo bleque de asignacion. 

Los sistemas de archivos que estan estructurados siguiendo esta logica de 
grupos de asignacion no evitan la fragmentacion, pero si la mayor parte de 
sus consecuencias negativas. Para mantener este esquema operando confiable- 
mente, eso si, requieren de mantener disponibilidad de espacio — al presentar- 
se saturacion, esta estrategia pierde efectividad. Para evitar que esto ocurra, es 
muy frecuente en los sistemas Unix que haya un cierte percentaje (tipicamen- 
te cercane a 5%) del disco disponible unicamente para el administrader — en 
case de que el sistema de archivos pase de 95%, los usuarios no podran escri- 
bir en el, pere el administrader puede efectuar tareas de mantenimiento para 
velver a un range eperacienal. 

7.3. Fallos y recuperacion 

El sistema de archivos FAT es relativamente frdgil: no es dificil que se presente 
una situacion de corrupcion de metadatos, y muy particularmente, que esta afec- 
te la estructura de las tablas de asignacion. Los usuarios de sistemas basados 
en FAT en Windows sin duda conocen a CHKDSK y SCANDISK, dos programas 
que implementan la misma funcionalidad base, y difieren principahnente en 
su interfaz al usuario: CHKDSK existe desde los primeros anos de MS-DOS, y es- 
ta pensado para su uso interactive en Hnea de comando; SCANDISK se ejecuta 
desde el entorno grafico, y presenta la particularidad de que no requiere (aim- 
que si recomienda fuertemente) acceso exclusivo al sistema de archivos mientras 
se ejecuta. 

^Como es el funcionamiento de estos programas? 

A lo largo de la vida de un sistema de archivos, conforme los archivos se 
van asignando y liberando, cambian su tamano, y conforme el sistema de ar- 

^'Claro estA, en el caso de los archivos que est&i como ligas duras desde varies directorios, pue- 
den ubicarse s61o cerca de uno de ellos. 
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chivos se monta y desmonta, pueden ir apareciendo inconsistencias en su es- 
tructura. En los sistemas tipo FAT, las principales inconsistencias^*^ son: 

Archives cruzados {cross-linked file) Recuerdese que la entrada en el directorio 
de un archivo incluye un apuntador al primer cluster de una cadena. Cada 
cadena debe ser unica, esto es, ningun cluster debe pertenecer a mas de 
im archivo. Si dos archivos rncluyen al mismo cluster, esto indica una in- 
consistencia, y la unica forma de resolverla es truncar uno de los archivos 
en el punto inmediato anterior a este cruce. 

Cadenas perdidas o huerfanas (lost clusters) Cuando hay espacio marcado co- 
mo ocupado en la tabla de asignacion, pero no hay ninguna entrada de 
directorio haciendo referenda a ella, el espacio esta efectivamente blo- 
queado y, desde la perspectiva del usuario, inutilizado; ademas, estas ca- 
denas pueden ser un archivo que el usuario aiin requiera. 

Este problema resulto tan frecuente en versiones historicas de Unix que 
incluso hoy es muy comun tener un directorio llamado lost + founden 
la ralz de todos los sistemas de archivos, donde f sck (el equivalente en 
Unix de CHKDSK) creaba ligas a los archivos perdidos por corrupcion de 
metadatos. 

Cada sistema de archivos podra presentar un distinto conjunto de incon- 
sistencias, dependiendo de sus estructuras basicas y de la manera en que cada 
sistema operativo las maneja. 



directorio 




Figura 7.8: Inconsistencias en un sistema de archivos tipo FAT. 



^"Que no las unicas. Estas y otras mas estan brevemente descritas en la pagina de manual de 
dosf sck (vease la seccion 7.4.3). 
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En la decada de los 1980 comenzaron a venderse los controladores de disco 
inteligentes, y en menos de 10 anos dominaban ya el mercado. Estos controla- 
dores, con interfaces flsicas tan disimiles como SCSI, IDE, o los mas modemos, 
SAS y SATA, introdujeron muchos cambios que fueron disociando cada vez mas 
al sistema operativo de la gestion fisica directa de los dispositivos; en el apen- 
dice C se presenta con mayor profundidad lo que esto ha significado para el 
desarroUo de sistemas de archives y algoritmos relacionados. Sin embargo, pa- 
ra el tema en discusion, los controladores inteligentes resultan relevantes porque, 
si bien antes el sistema operativo podia determinar con toda certeza si una 
operacion se habla realizado o no, hoy en dia los controladores dan ujti acuse de 
recibo a la informacion en el momento en que la colocan en el cache incorpora- 
do del dispositivo — en caso de un fallo de corriente, esta informacion puede 
no haber sido escrita por completo al disco. 

Es importante recordar que las operaciones con los metadatos que confor- 
man el sistema de archivos no son atomicas. Por poner un ejemplo, crear un 
archivo en vin volumen fat requiere: 

1. Encontrar una lista de clusters disponibles suficiente para almacenar la 
informacion que conformara al archivo. 

2. Encontrar el siguiente espacio disponible en el directorio. 

3. Marcar en la tabla de asignacion la secuencia de clusters que ocupara el 
archivo. 

4. Crear en el espacio encontrado una entrada con el nombre del archivo, 
apuntando al primero de sus clusters. 

5. Guardar los datos del archivo en cuestion en los clusters que correspon- 
dan. 

Cualquier fallo que se presente despues del tercer paso (tras efectuarse la 

primera modificacion) tendra como consecuencia que el archivo resulte corrup- 
to, y muy probablemente todo que el sistema de archivos presente inconsistencias 
o este en un estado inconsistente. 

7.3.1. Datos y metadatos 

En el ejemplo recien presentado, el sistema de archivos estara en un estado 
consistente siempre que se terminen los pasos 3 y 4 — la consistencia del siste- 
ma de archivos es independiente de la validez de los datos del archivo. Lo que 
busca el sistema de archivos, mas que garantizar la integridad de los datos de 
vno de los archivos, es asegurar la de los metadatos: los datos que describen la 
estructiira. 
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En caso de que un usuario desconecte una unidad a media operacion, es 
muy probable que se presente perdida de inf ormacion, pero el sistema de archi- 
ves debe buscar no presentar ningiin problema que ponga en riesgo operaciones 
posteriores o archivos no relacionados. La corrupcion y recuperacion de datos en 
archivos corruptos y truncados, si bien es tambien de gran unportancia, cae 
mas bien en el terreno de las aplicaciones del usuario. 

7.3.2. Verificacion de la integridad 

Cada sistema operativo incluye programas para realizar verificacion (y, en 
su caso, correccion) de la integridad de sus sistemas de archivo. En el ca- 
so de MS-DOS y Windows, como ya se vio, estos programas son CHKDSK y 
SCANDISK; en los sistemas Unix, el programa general se llama f sck, y tipi- 
camente emplea a asistentes segiin el tipo de sistema que haya que revisar — 
f sck . vf at, f sck . ext2, etcetera. 

Estos programas hacen un barrido del sistema de archivos, buscando evi- 
dencias de inconsistencia. Esto lo hacen, en Imeas generales: 

■ Siguiendo todas las cadenas de clusters de archivos o tablas de i-nodos, y 
verificando que no haya archivos cruyados (compartiendo erroneamente 
bloques). 

■ Verificando que todas las cadenas de clusters, as! como todos los directo- 
rios, sean alcanzables y sigan \ma estructura valida. 

■ Recalculando la correspondencia entre las estructuras encontradas y los 
diferentes bitmaps y totales de espacio vaclo. 

Estas operaciones son siempre procesos intensivos y complejos. Como re- 

quieren una revision profunda del volumen entero, es frecuente que duren en- 
tre decenas de minutos y horas. Ademas, para poder Uevar a cabo su tarea 
deben ejecutarse teniendo acceso exclusive al volumen a revisar, lo cual tipica- 
mente significa colocar al sistema complete en modo de mantenimiento. 

Dado el elevado costo que tiene verificar el volumen entero, en la decada 
de los noventa surgieron varies esquemas erientades a evitar la necesidad de 
invocar a estos programas de verificacion: las actualizaciones suaves, los sistemas 
de archivos con bitdcora, y los sistemas de archivos estructurados en bitdcora. 

7.3.3. Actualizaciones suaves 

El esquema de actualizaciones suaves {soft updates) aparentemente es el mas 
simple de los que se presentan, pero su implementacion resulto mucho mas 
compleja de lo inicialmente estimado y, en buena medida, por esta causa no 
ha sido empleado mas ampliamente. La idea basica detras de este esquema es 
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estructurar el sistema de archivos de una forma mas simple y organizar las es- 
crituras del mismo de modo que el estado resultante no pueda ser inconsistente, 
ni siquiera en caso de fallo, y de exigir que todas las operaciones de actualiza- 
cion de metadatos se realicen de forma smcrona.^^ 

Ante la imposibilidad de tener un sistema siempre consistente, esta exigencia 
se relajo para permitir inconsistencias no destructivas: pueden presentarse cade- 
nas perdidas, dado que esto no pone en riesgo a ningiin archivo, solo disminuye 
el espacio total disponible. 

Esto, aunado a una reestructuracion del programa de verificacion (f sck) 
como una tarea ejecutable en elfondo^ y en una tarea de recolector de basura, que 
no requiere intervencion humana (dado que no pueden presentarse inconsis- 
tencias destructivas), permite que un sistema de archivos que no fue limpia- 
mente desmontado pueda ser montado y utilizado de inmediato, sin peligro de 
perdida de informacion o de corrupcion. 

Al requerir que todas las operaciones sean smcronas, pareceria que el ren- 
dimiento global del sistema de archivos tendria que verse afectado, pero por 
ciertos patrones de acceso muy frecuentes, resulta incluso beneficioso. Al man- 
tenerse \m ordenamiento logico entre las dependencias de todas las operacio- 
nes pendientes, el sistema operativo puede combinar muchas de estas y reducir 
de forma global las escrituras a disco. 

A modo de ejemplos: si varios archivos son creados en el mismo directorio 
de forma consecutiva, cada uno de ellos mediante una Uamada open () in- 
dependiente, el sistema operativo combinara todos estos accesos en uno solo, 
reduciendo el numero de llamadas. Por otro lado, un patron frecuente en sis- 
temas Unix es que, para crear un archivo de uso temporal reforzando la con- 
fidencialidad de su contenido, el proceso solicite al sistema la creacion de un 
archivo, abra el archivo recien creado, y ya teniendo al descriptor de archivo, lo 
elimine — en este caso, con estas tres operaciones seguidas, soft updates podria 
ahorrarse por complete la escritura a disco. 

Esta estrategia se vio afectada por los controladores inteligentes: si un disco 
esta sometido a carga intensa, no hay garantia para el sistema operativo del 
orden que seguiran en verdad sus solicitudes, que seforman en el cache propio 
del disco. Dado que las actualizaciones suaves dependen tan profundamente 
de confiar en el ordenamiento, esto rompe por completo la confiabilidad del 
proceso. 

Las actualizaciones suaves fueron implementadas hacia 2002 en el sistema 
operativo FreeBSD, y fueron adoptadas por los principales sistemas de la fami- 
lia BSD, aimque NetBSD lo retiro en 2012, prefiriendo el empleo de sistemas con 
bitacora, tema que sera tratado a continuacion. Muy probablemente, la logica 
destras de esta decision sea la cantidad de sistemas que emplean esta segimda 

^^Esto es, no se le reporta exito en alguna operaci6n de archivos al usuario sino hasta que 6sta es 
completada y grabada a disco. 

^^Una tarea que no requiere de intervenci6n manual por parte del operador, y se efectiia de 
forma automdtica como parte de las tareas de mantenimiento del sistema. 
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estrategia, y lo complejo que resulta dar mantenimiento dentro del niicleo dos 
estrategias tan distintas. 



7.3.4. Sistemas de archive con bitacora 

Este esquema tiene su origen en el ambito de las bases de datos distribui- 
das. Consiste en separar un area del volumen y dedicarla a llevar una bitacora 
(journal) con todas las transacciones de metadatos.-^^ Una transaccion es un con- 
jiinto de operaciones que deben aparecer como at6micas. 

La bitacora se implementa generaknente como vina lista ligada circular, con 
un apuntador que indica cual fue la ultima operacion realizada exitosamente. 
Periodicamente, o cuando la carga de transferencia de datos disminuye, el sis- 
tema verifica que operaciones quedaron pendientes, y avanza sobre la bitacora, 
marcando cada una de las transacciones conforme las realiza. 

En caso de tener que recuperarse de una condicion de fallo, el sistema ope- 
rativo solo tiene que leer la bitacora, encontrar cual fue la ultima operacion 
efectuada, y aplicar las restantes. 

Una restriccion de este esquema es que las transacciones guardadas en la 
bitacora deben ser idempotentes — esto es, si una de ellas es efectuada dos ve- 
ces, el efecto debe ser exactamente el mismo que si hubiera sido efectuada una 
sola vez. Por poner un ejemplo, no serfa valido que una transaccion indicara 
"agregar al directorio x un archive llamado y", dado que si la falla se produ- 
ce despues de procesar esta transaccion pero antes de avanzar al apuntador 
de la bitacora, el directorio x quedaria con dos archivos y — ^ima situacion in- 
consistente. En todo caso, tendriamos que indicar "registrar al archive y en la 
posicion z del directorio x"; de esta manera, incluso si el archivo ya habia sido 
registrado, puede volverse a hacerlo sin peligro. 

Este esquema es el mas utilizado hoy en dla, y esta presente en casi todos 
los sistemas de archivos modemos. Si bien con un sistema con bitacora no hace 
falta verificar el sistema de archivos complete tras una detencion abrupta, esta 
no exime de que, de tiempo en tiempo, el sistema de archivos sea verificado: 
es altamente recomendado hacer una verificacion periodica en caso de presen- 
tarse alguna corrupcion, sea por algtin bug en la implementacion, fallos en el 
medio flsico, o factores similarmente poco frecuentes. 

La mayor parte de los sistemas de archivos incluyen contadores de cantidad 
de montajes y defecha del ultimo montaje, que permiten que el sistema operative 
determine, de forma autematica, si correspende hacer una verificacion preven- 
tiva. 



^^Hay implementaciones que registran tambien los datos en la bitacora, pero tanto por el tamano 
que 6sta requiere como por el efecto en velocidad que significa, son poco utilizadas. La seccibn 7.3.5 
presenta una idea que elabora sobre una bitacora que almacena tanto datos como metadatos. 
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Figura 7.9: Sistema de archives con bitacora. 



7.3.5. Sistemas de archives estructurados en bitacora 

Si se lleva el concepto del sistema de archives con bitacora a su limite, y 
se designa a la totalidad del espacio en el volumen como la bitacora, el resulta- 
do es un sistema de archivos estructumdo en bitacora {log-structured file systems). 
Obviamente, este tipo de sistemas de archivos presenta una organizacion com- 
pleta radicalmente diferente de los sistemas de archivo tradicionales. 

Las ideas basicas detras de la primer implementacion de un sistema de ar- 
chivos de esta naturaleza (Ousterhut y Rosenblum, 1992) apuntan al empleo 
agresivo de cache de gran capacidad, y con un fuerte mecanismo de recolec- 
cion de basura, reacomodando la rnformacion que este mas cerca de la cola de la 
bitacora (y liberando toda aquella que resulte redundante). 

Este tipo de sistemas de archivos facilita las escrituras, haciendolas siem- 
pre secuenciales, y buscan -por medio del empleo del cache ya mencionado- 
evitar que las cabezas tengan que desplazarse con demasiada frecuencia para 
recuperar fragmentos de archivos. 

Una consecuencia directa de esto es que los sistemas de archivos estructura- 
dos en bitacora fueron los primeros en ohecer fotograflas {snapshots) del sistema 
de archivos: es posible apuntar a un momento en el tiempo, y -con el sistema 
de archivos aun en operacion- montar una copia de solo lectura con la infor- 
macion del sistema de archivos completa (uicluyendo los datos de los archivos). 

Los sistemas de archivo estructurados en bitacora, sin embargo, no estan 
optimizados para cualquier carga de trabajo. Por ejemplo, una base de datos re- 
lational, en que cada uno de los registros es tipicamente actualizado de forma 
independiente de los demas, y ocupan apenas fracciones de un bloque, resul- 
taria tremendamente uieficiente. La implementacion referenda de Ousterhut y 
Rosenblum fue parte de los sistemas BSD, pero dada su tendencia a la extrema 
fi-agmentacion, fue eliminado de ellos. 
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Este tipo de sistemas de archivo ofrece caracteristicas muy interesantes, 
aunque es un campo que aun requiere de mucha investigacion e implemen- 
taciones ejemplo. Muchas de las implementaciones en sistemas libres han Ue- 
gado a niveles de funcionalidad aceptables, pero por diversas causas han ido 
perdiendo el interes o el empuje de sus desarrolladores, y su ritmo de desarro- 
Uo ha decrecido. Sin embargo, varios conceptos muy importantes han nacido 
bajo este tipo de sistemas de archivos, algunos de los cuales (como el de las 
fotograflas) se han ido aplicando a sistemas de archivo estandar. 

Por otro lado, dado el fuerte crecimiento que estan registrando los medios 
de ahnacenamiento de estado solido (en la seccion C.1.2 se abordaran algunas 
de sus particularidades), y dado que estos sistemas logran aprovechan mejor 
varias de sus caracteristicas, es probable que el interes en estos sistemas de 
archivos resiurja. 

7.4. Ejercicios 

7.4.1. Preguntas de autoevaluacion 

1. Asuma el siguiente sistema de archivos basado en asignacion indexada. 
Cada duster mide 4 096 bytes, y el apuntador a un bloque requiere 32 
bits (4 bytes). Dados los metadatos que van a ahnacenarse en el i-nodo 
del archivo, dentro del i-nodo principal puede guardar 24 apuntadores 
directos, y esta considerando permitir indireccion senciUa y doble. 

iCual es el tamano maximo de archivo que podra manejar este sistema 
de archivos? 

2. El sistema de archivos Reiser esta basado en la asignacion indexada, pero 
introduce un nuevo concepto: las colitas (tails). Estas permiten que dis- 
tintos archivos pequenos, de hasta 4 KB, puedan ser almacenados en un 
mismo cluster. Esto permite a Reiser ahorrar espacio en disco (se estima 
que logra una eficiencia hasta 5% mayor que sistemas que no emplean 
esta tecnica), y ademas reduce el tiempo requerido para recuperar estos 
archivos, dado que los datos pueden almacenarse en el mismo i-nodo que 
alguna de sus bibliotecas, sin requerir leer ningiin bloque adicional. 

Reiser se popularize alrededor del 2001, pero su desarrollo se ha deteni- 
do, y esta caracterfstica en particular no ha sido adoptada mas que por 
unos pocos sistemas de archivos (UFS2 y btrfs). ^Que problemas encuen- 
tra con el planteamiento de las colitas? 

3. Describa el funcionamiento de un sistema de archivos con bitdcora (jouma- 
lingfile system). ^Como nos asegura que el sistema se mantendra consis- 
tente despues de una interrupcion abrupta del suministro electrico? 
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7.4.2. Temas de investigacion sugeridos 

Desduplicacion Una de las caracteristicas que ofrecen varios sistemas opera- 
tives de ultima generacion es la desduplicacion, presentada en la seccion 
7.1.5: la deteccion de sectores identicos pertenecientes a mas de vin archi- 
vo, para evitar repetirlos varias veces en el disco (es un fenomeno que 
ocurre mucho mas de lo que esperariamos). Esta deteccion se realiza ti- 
picamente por medio de hashes criptogrdficos. 

^Como opera un poco mas a detalle este mecanismo, que tan confiable es? 
(esto es, ise recomienda utilizar ya en sistemas en produccion?) iQue tan 
eficiente resulta con los datos que se encuentran tipicamente, que pasa 
con el espacio libre reportado al sistema, no se cae en riesgos de sobre- 
comprometimiento (overcommit)? Respecto a su forma de operacion, ique 
diferencias tienen la desduplicacion en Unea y la desduplicacion fuera de Imea 
{online deduplication, offline deduplication), Como opera el hash criptogrdfico? 
Y de forma general, ihay veces que este mecanismo resulte insuficiente, 
que alternativas hay? 

Como referenda informal al respecto, sugiero leer el siguiente hilo de 
discusion al respecto en la lista de DebConf (el congreso de Debian): 

http://lists.debconf.org/lurker/message/20130813.100610.f38cd67f.en.html 

7.4.3. Lecturas relacionadas 

■ Practical File System Design 

http : / /www. nobius . org/~dbg/ 

Dominic Giampaolo (1999). El autor f ue parte del equipo que implement© 
el sistema operative BeOS, un sistema de alto rendimiento pensado para 
ejecutar en estaciones de alto rendimiento, particularmente enfocado al 
video. El proyecto fracaso a la larga, y BeOS (asi como BeFS, el sistema que 
describe) ya no se utilizan. Este libro, descargable desde el sitio Web del 
autor, tiene una muy buena descripcion de varios sistemas de archives, 
y aborda a profundidad tecnicas que hace 15 anos eran verdaderamente 
novedosas y hoy forman parte de casi todos los sistemas de archives con 
use amplie, e incluse algunas que no se han legrade implementar y que 
BeFS si efrecia. 

■ Processes as Files 

http://lucasvr. gobolinux . org/etc/Killian84-Procf s-USENIX .pdf 
T. J. Killian (1984) 

■ A method for the construction of Minimum-Redundancy Codes 

http : / / compression . graphicon . ru/ download/ articles/huf f /huf fman_ 

1 952_ininimum- redundancy- codes . pdf 

David A. Huffman (1952); Proceedings of the I. R. E 
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■ FAT Root Directory Structure on Floppy Disk and File Information 

http : / / www . codeguru . com/ cpp/cpp/ cpp_mfc/ files/ article . php/ cl3831 
Mufti Mohammed (2007); Codeguru 

■ File Allocation Table: ISbit 

http : / /www .beginningto seethe light .org/ fat 16/ index . htm) 
Peter Clark (2001) 

■ Dosfsck: check and repair MS-DOS filesystems 

http : / / www . linuxcommand . org/man_pages/ dosf sck8 . html 
Werner Almesberger (1997) 

■ A Fast File System for Unix 

http : / /www . cs . berkeley . edu/ -brewer/ cs262/FFS .pdf ) 

Marshall Kirk Mckusick, William N. Joy, Samuel J. Lefler, Robert S. Fabry 

(1984); ACM Transactions on Computer Systems 

■ The Design and Implementation of a Log-Structured File System 
http : / /www . cs . berkeley . edu/ -brewer/ cs2 62 /LFS .pdf 

Mendel Rosenblum, J. K. Ousterhout (1992); ACM Transactions on Com- 
puter Systems 

■ The Second Extended File System: Internal Layout 

http : / /www . nongnu . org/ext2-doc/ ) 
Dave Poirier (2001-2011) 

■ NILFS2 en Linux 

http: //cyanezfdz .me/articles/2012/08/nilfs2 .html 
Cesar Yanez (2012) 

■ Disks from the Perspective of a File System 

http:// queue. a cm .org/detail.cfm?id=2367378 
Marshall Kirk McKusick (2012); ACM Queue 

• Traduccion al espanol: Los discos desde la perspectiva de un sistema de 
archivos 

http : / /cyanezfdz . me/post /los-discos-desde-la-perspectiva-de-un-sistema-de-i 
Cesar Yanez (2013) 

■ A hash-based DoS attack on Btrfs 

http: // lwn.net /Articles/ 52 907 7/ 
Jonathan Corbet (2012); Linux Weekly News 

■ Default /etc/apachel/mods-available/disk^.Qche-'^onfis incompatible with ext3 
http: //bugs .debian.org/682 84 0 

Christoph Berg (2012). Reporte de fallo de Debian Uustrando los Hmites 
en mimeros de archivos para Ext3. 
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■ File-system development with stackable layers 

https : //dl . acm. org/citation. cfm?id=17 4 613 .17 4 616 

Heidemarm y Popek (1994); ACM Transactions on Computer Systems 

■ Serverless network file systems 

https : //dl . acm. org/citation. cfm?id=2 2 5535 .22 5537 

Thomas E. Anderson et. al. (1996); ACM Transactions on Computer Sys- 
tems 

■ Log-structured file systems: There's one in every SSD 
https : //lwn.net/Articles/353411/ 
Valerie Aurora (2009); Linux Weekly News 



Apendice A 



Software libre y 
licenciamiento 

A.l. Software libre 

Este apendice, a diferencia del resto del libro, no se enfoca a asuntos tecni- 
cos, sino que a un aspecto social: a la construccion del conocimiento de forma 
colectiva, colaborativa, que ha resultado en el movimiento del software libre. 

Si bien este tema es meramente tangente al que desarrolla el libro, los auto- 
res consideran importante incluirlo no solo por la importancia que el software 
libre ha tenido para el desarrollo y estudio de los sistemas operativos, sino que 
directamente -como se explica en la seccion A.2- para el presente libro en par- 
ticiilar. 

A.1.1. Free as in Freedom: el proyecto GNU 

Citando la definicion que brinda la Fundacion del Software Libre (Free Soft- 
ware Foundation), el software libre es todo programa en el cual los usuarios tie- 
nen la libertad para ejecutar, copiar, distribuir, estudiar, modificar y mejorar el soft- 
ware. Esto es, todo programa cuyo modelo de licenciamiento respete las cuatro 
libertades del software: 

■ La libertad de ejecutar el programa para cualquier proposito. 

■ La libertad de estudiar como funciona el programa, y cambiar- 
lo para que haga lo que usted quiera. El acceso al codigo fuente 
es una condicion necesaria para ello. 

■ La libertad de redistribiiir copias para ayudar a su projimo. 

■ La libertad de distribuir copias de sus versiones modificadas a 
terceros. Esto le permite ofrecer a toda la comunidad la opor- 
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tunidad de beneficiarse de las modificaciones. El acceso al c6- 
digo fuente es una condicion necesaria para ello. 

El software libre en tanto movimiento ideologico tiene bien identificados sus 
origenes y genesis: en septiembre de 1983, Richard M. Stallman anuncio el na- 
cimiento del Proyecto GNu/ que buscaba crear \m sistema operative tipo Unix, 
junto con todas las herramientas basicas del sistema (partiendo naturalmente 
desde la creacion de un entorno de edicion y ujn compilador). Tras sistematizar 
los fundamentos del proyecto, en marzo de 1985 Stallman publico el Manifies- 
to GNU, documento que hoy es lectura obligada para comprender al fenomeno 
que nacio en ese momento. 

Algunos meses mas tarde, en octubre de 1985, creo la Fundacion de Software 
Libre (fsf. Free Software Foundation), enfocada en la consecucion de fondos para 
impulsar la creacion de dicho sistema, en dar a conocer su trabajo, tanto para 
lograr que fuera ampliamente utilizado como para reclutar a mas programa- 
dores y acelerar su ritmo de desarroUo. 

El trabajo de la FSF es desde cualquier optica impresionante por su mag- 
nitud y por su envergadura tecnica. Sin embargo, probablemente su mayor 
contribucion sea la Licencia Publica General (General Public License, GPL), que 
sera abordada en la seccion A.1.4. 

A.1.2. El software libre antes de GNU 

El software libre como hoy se conoce existio mucho antes del nacimiento 
del Proyecto GNU: era la norma practicamente hasta la aparicion de las compu- 
tadoras personales. 

Los sistemas operatives, las herramientas de sistema y los compiladores 
eran, en un principio, entregados por los fabricantes junto con el equipo de 
computo no solo como objetos binarios, sino como codigo fuente. Esto era na- 
tural: los operadores de las computadoras no limitaban su uso a adecuar el 
software, sino que era comun que adecuaran tambien el hardware: cada equi- 
po instalado era, hasta cierto punto, linico. 

Para hacerlo, claro, casi siempre era necesario modificar al software de for- 
ma correspondiente. Esto requerla el acceso al codigo fuente, e impHcitamente 
pasaba por las cuatro libertades ya enunciadas. 

Durante las primeras decadas, practicamente la totalidad del desarrollo del 
computo se Uevo a cabo siguiendo la tradicion academical los programas eran 
distribuidos, ya fuera en cintas o incluso en listados impresos, requiriendo uni- 
camente -como en un artlculo cientifico- que se preserve la atribucion de autorta. 
Solo de este modo puede entenderse el desarrollo (y la supervivencia hasta el 
dla de hoy) de sistemas con la relevancia de CP-CMS, creado por la muy prag- 



^Con el particular sentido del humor que caracteriza a Stallman, las siglas que eligib para el 
proyecto, GNU, son tm acrmimo recursivo, signiflcan GNU is Not Unix: GNU no es Unix. 
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matica y corporativa empresa IBM y cuya progenie sigue empleandose como 
niicleo de su arquitectura de virtualizacion z/VM (vease la seccion B.3) o Unix. 

Unix nacio como una reaccion al sistema operativo Multics, desarroUado 
principalmente entre 1965 y 1970, y en el que participaban de forma conjun- 
ta varias empresas y el Instituto de Tecnologfa de Massachusetts (MIT). Mul- 
tics resulto un proyecto demasiado grande y AT&T lo abandono en 1969; del 
equipo de AT&T que trabajaba en Unix, dos de los desarrolladores (Ken Thom- 
pson y Dennis Ritchie) comenzaron a escribir en 1969 un sistema mucho menos 
ambicioso, tomando algunos de los principales criterios de diseno, pero sim- 
plificando fuertemente el modelo de usuario y los requisitos en hardware. El 
nombre de Unix (originalmente Unics) es, de hecho, \ma broma sobre el nom- 
bre Multics. 

Citando a Dennis Ritchie: 

Lo que querlamos preservar no solo era un buen ambiente en el cual 
programar, sino que un sistema alrededor del cual pudiera formar- 
se una cofradfa. Sabfamos por experiencia propia que la esencia del 
computo comunal, provisto por computadoras de acceso remoto y 
tiempo compartido, no se limita unicamente a escribir programas 
en una terminal en vez de emplear tarjetas perforadas, sino que fa- 
vorece la comunicacion cercana. 

El parrafo inicial de este apendice, que hace referenda a la naturaleza social 
del software libre, resuena con esta cita. El desarrollo de software va mucho 
mas alia de su efecto tecnico: es una actividad tan social como cualquier otro 
desarrollo intelectual. 

A lo largo de sus primeros 10 anos de vida, Unix paso rapidamente de ser 
un sistema de juguete a ser, sin proponerselo, la base de desarrollo tecnologico 
sobre la cual se tendieron las bases de Internet. Decenas de empresas y univer- 
sidades obtuvieron copias de Unix y lo modificaron, agregan.do funcionalidad 
— y compartiendo esta nueva funcionalidad con el resto de la comunidad que se 
formo alrededor de Unix. 

A.1.3, El software propietario como anomalia historica 

La anomalia historica resulta, mas bien, el auge que tuvo el software propie- 
tario o privativo? Una de las probables razones para este puede ser, paradojica- 
mente, el nacimiento del segmento del computo aficionado, como los presenta- 
dos en la seccion 1.4: las primer as computadoras personales carecfan del alma- 
cenamiento y poder de computo suficiente para siquiera compilar sus propios 
entornos operativos, razon por la cual las empresas productoras recurrieron a 
m\a distribucion exclusivamente binaria. 



^Se designa de esta forma al software no-libre. 



300 



APENDICE A. SOFTWARE LIBRE Y LICENCIAMIENTO 



El inicio de la masificacion del computo llevo a que varias empresas nacien- 
tes identificaran un nicho de mercado donde podrian vender licencias de uso de 
los programas que produjeran, cobrando relativamente poco por cada licencia, 
pero aspirando a vender un gran volumen. 

En este sentido, vale mucho la pena leer la carta abierta a los entusiastas que 
Bill Gates, socio de la entonces naciente y pequena empresa Micro-Soft publico 
en varias revistas de computo personal; la publicacion original fue en el Home- 
brew Computer Club Newsletter {Periodico del Club de Computo Casero) en enero de 
1976, y fue replicado en varias otras revistas. 

Esta carta abierta tuvo amplias repercusiones, y desato un interesante de- 
bate que los lectores interesados podran encontrar (y seguir en copias de los 
textos originales) desde el articulo de Wikipedia repecto a esta carta abierta. 

A.1.4. Esquemas libres de licenciamiento 

Las licencias resultan fundamentals para comprender al software libre, 
tanto en su planteamiento ideologico primigenio como en el tipo de comu- 
nidad de desarrollo que aglutinan. Lo que es mas, solo se puede hablar de soft- 
ware libre en tanto este asociado a un esquema de licenciamiento, dado que es 
este el que determina las condiciones de uso a que estara sujeto un programa.^ 

A continuacion, se abordan los dos principales enfoques del licenciamiento 
libre. 

Licenciamiento academico/permisivo: Mix, BSD, xll, etcetera 

Las licencias derivadas del primer momento del software libre descrito son, 
en su conjunto, como licencias academicas o permisivas. Esto es porque, sin dejar 
de cubrir las cuatro libertades presentadas al principio del presente apendice, el 
linico requisito que imponen ante el usuario o distribuidor es el de la atribucion. 

De ahi el simil con la academia. No es de sorprender que algimas de las 
licencias mas frecuentemente referidas de este tipo provengan directamente 
del ambito Universitario: la licencia MIT proviene del Instituto de Tecnologfa de 
Massachusetts (ampliamente conocido bajo dicha sigla), y la licencia BSD hace 
referenda a la Distribucion de Software de Berkeley, una de las principales ramas 
del desarrollo historico de Unix, lidereada por la Universidad de California en 
Berkeley. 

Hay decenas de licencias que caben en esta categorfa, con variaciones relati- 
vamente muy menores entre ellas. Los principales puntos que tienen en comiin 
son: 

^Todos los paises firmantes de la Convencion de Berna garantizan la proteccion del derecho 
de autor sin necesidad de registro, de donde deriva que todo programa que sea publicado sin una 
licencia que expresamente lo haga Ubre, estard sujeto a todos los derechos reseroados: prohibici6n a todo 
tipo de uso sin autorLzaci6n expresa y expllcita del autor. 
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■ Licencias muy cartas. Siendo documentos legales, son muy sencillas y no 
dejan espacio a interpretaciones ambiguas. 

■ Se limitan a autorizar expresamente el use del software, en fuente o en 
binario, y a rechazar cualquier reclamo de garantta o responsabilidad par su 
uso. 

■ Penniten la derivacion en proyectos propietarios. 

Una critica reiterada al uso de estos esquemas de licenciamiento por parte 
de la FSF es que permiten la privatizacion de mejorias hechas al software libre 
— ^pero al mismo tiempo, este puxito constituye una de las principales fortalezas 
de este licenciamiento. 

La masificacion de Internet, y su adopcion en los sistemas operativos mas 
variados, se debio en gran parte a que el desarrollo de los protocolos que con- 
forman TCP/IP fue liberado bajo un licenciamiento tipo BSD. Al dia de hoy, 
muchos de los componentes fundamentals de conectividad en practicamente 
la totalidad de sistemas operativos siguen incluyendo la nota de que los de- 
rechos de autor de determinados componentes pertenecen a los regentes de la 
Universidad de California. 

Dado que empresas tan dispares como Sun Microsystems, Digital Research, 
IBM, Hewlett-Packard, Microsoft y Apple (por mencionar solo a las que han di- 
rigido distintos aspectos del mercado del computo) pudieron adoptar esta pila 
ya desarrollada, y que habia una masa critica de sistemas abiertos empleando 
TCP/iP, este protocolo de red credo hasta eclipsar a las diferentes apuestas 
propietarias de las diferentes empresas. Posteriormente, con el auge de los sis- 
temas operativos libres, estos pudieron tambien adoptar esta base tecnologica 
en igualdad de condiciones. 

Licenciamiento Copyleft: GPL, LGPL, MFL, CDDL, etcetera 

Para la FSF, el desarrollo de software es expHcitamente un hecho social, y la 
Creadon de un sistema libre es un imperativo etico. La principal herramienta 
que emplearon para difundir y exigir la libertad del software fue el conjunto 
de licencias Copyleft.^ Y como se vio, si bien esto podria no ser compartido por 
los diferentes actores (personas y empresas), el desarrollo de Unix partio desde 
este mismo punto de vista. 

Como se menciono al inicio del presente apendice, una de las principales 
obras de la FSF fue la creacion de un modelo de licenciamiento que expresa este 
imperativo etico: una familia de licencias cuyos principales exponentes son la 
Licenda Publica General (General Public License, GPL) y la Licencia Publica General 
para Bibliotecas {Library General Public License, LGPL, hoy renombrada a Licencia 
Publica General Disminuida, Lesser General Public License). 



■*T6rauno empleado para contraponerse a la noci6n de Copyright, derecho de autor. 



302 



APENDICE A. SOFTWARE LIBRE Y LICENCIAMIENTO 



Hay varios ejemplos de licenciamiento que siguen estas ideas basicas; pro- 
bablemente los mas importantes sean la Licencia Puhlica deMozilla (mpl, por sus 
siglas en ingles) o la Licencia Comun de Distribucion y Desarrollo (CDDL, por sus 
siglas en ingles, creada por Sun Microsystems), y su principal diferencia con las 
presentadas por la FSF es que fueron propuestas no por grupos idealistas para 
el desarrollo de software aiin inexistente, sino que por empresas que teman ya 
\m cuerpo de software, y encontraron este modelo como el mas sustentable para 
continuar su desarrollo. 

La principal caracteristica de estos esquemas es que permiten el uso del 
software para cualquier fin, imponiendo como linica condicion que, en caso de 
redistribucion (ya sea en su estado original o con modificaciones), el destinatario 
no solo reciba el objeto binario ejecutable sino que el codigo fuente del cual este 
provino, bajo las mismas condiciones de licenciamiento original. 

Este esquema asegura que lo que una vez fue software libre Cojn/left siem- 
pre lo siga siendo. El licenciamiento GPL ha llevado a que muchas empresas 
empleen al sistema operativo Linux como base para su desarrollo contribuyan 
sus cambios de vuelta a la comuxiidad — convirtiendo a Linux al paso de los 
afios de un sistema relativamente aficionado y con mediocre soporte a hard- 
ware en uno verdaderamente solido y universal. 

Muchos han criticado a este espmtu viral de las Hcencias Copyleft: una vez 
que un proyecto incorpora componentes GPL, esta licencia podria infectar al 
proyecto entero obUgandolo a adoptar esta Hcencia, resultando en graves per- 
juicios para las empresas que invierten en desarrollo. Si bien esto se ha demos- 
trado falso repetidamente, sigue siendo un punto de propaganda frecuente- 
mente empleado para evitar el empleo de software libre. 

El objetivo del presente apendice no es entrar a desmenuzar las diferencias 
entre estos esquemas o resolver las controversias, sino linicamente presentarlos 
de forma descriptiva. 

A.2. Obras culturales libres 

Los distintos esquemas de software libre fueron logrando una. masa critica 
y poco a poco rompieron las predicciones de fracaso. Un ano crftico fue 1998, en 
que importantes proyectos propietarios decidieron migrar a im licenciamiento 
libre por resultar mas conveniente y sustentable. 

Ya con esta experiencia previa, y conforme el acceso a Internet se masificaba 
cada vez mas, comenzo a verse la necesidad de crear con esquemas similares de 
licenciamiento libre para otros productos de la creatividad humana, no linica- 
mente para el desarrollo del software. Si bien las licencias academicas podrian 
aplicarse sin demasiado problema a productos que no fueran software, las li- 
cencias Copyleft llevan demasiadas referencias al codigo fuente y al binario como 
parte de su definicion. 
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Del mismo modo que hay diferentes escuelas de pensamiento y puntos de vis- 
ta ideologicos que han Uevado al surgimiento de diversas licencias de software 
libre, respondiendo a distintas necesidades y matices ideologicos. 

El proyecto Wikipedia fue anunciado en enero del 2001. Al convocar a todo 
mundo y no solo a un manojo de especialistas, a crear contenido enciclopedico, 
este experimento, iniciado por Jimmy Wales y Larry Sanger, demostro que la 
creacion es un acto profundamente social. Miles de voluntarios de todo el mun- 
do han contribuido para hacer de la Wikipedia el compendio de conocimiento 
humano mas grande de la historia. Al nacer, la Wikipedia adopto el modelo 
de licenciamiento recomendado por la FSF para manuales y libros de texto: la 
Licencia de Documentacion Libre de GNU (GFDL, por sus siglas en ingles). 

El modelo de la GFDL resulta, sin embargo, de dificil comprension y apli- 
cacion para muchos autores, y la licencia no resulta apta para obras creativas 
mas alia de lo que puede tomarse como documentacion. 

El marco regulatorio de la Convencion de Bema, que rige al derecho de au- 
tor, estipula (como ya se menciono) que toda creacion plasmada en un medio 
fisico esta protegida, y todo uso no expresamente autorizado por una licencia 
expresa esta prohibido. La tarea de crear esquemas de licenciamiento aptos pa- 
ra lo que se fue definiendo como obras cuUurales libres resulto mas compleja por 
la riqueza de su expresion. En pocos anos hubo ima proliferacion de licencias 
que buscaban ayudar a los autores de obras creativas de todo tipo — no se 
abordaran los distintos intentos, sino que -aprovechando que la distancia en 
tiempo permiten simplificar- se tocara solo el esquema de licenciamiento que 
mas repercusion ha tenido. 

A.2.1. La familia de licencias Creative Commons 

En el ano 2001, el abogado estadounidense Larry Lessig indcio el proyecto 
Creative Commons (en adelante, CC). Citando del libro Construccion Colaborativa 
del Conocimiento (Wolf y Miranda, 2011): 

Pero no solo el conocimiento formalizado puede compartirse. En 
2001 nacio Creative Commons (cc), impulsada por el abogado es- 
tadounidense Larry Lessig. Esta organizacion liderada localmente 
en una gran cantidad de palses por personalidades versadas en te- 
mas legales, fue creada para servir como punto de referenda para 
quien quiera crear obras artfsticas, intelectuales y cientificas libres. 
Asimismo, ofrece un marco legal para que la gente no experta en 
estos temas pueda elegir los terminos de licenciamiento que juz- 
gue mas adecuados para su creacion, sin tener que ahondar de mas 
en las aridas estepas legales; se mantiene asesorada y liderada por 
un grupo de abogados, cuya principal labor es traducir y adecuar 
las licencias base de CC para cada una de las jurisdicciones en que 
sean aplicables. Alrededor de este modelo ha siirgido un grupo de 
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creadores, y una gran cantidad de sitios de alto perfil en la red han 
acogido su propuesta. Si bien no todas las licencias de CC califican 
como cultura libre, algimas que claramente si lo son han ayudado 
fuertemente a llevar estas ideas a la conciencia general. 

El grupo CC creo \m conjunto de licencias, permitiendo a los autores expre- 
sar distintos ^rados de libertad para sus obras. Uno de los principales elementos 
para su exito y adopcion masiva fue simplificar la explicacion de estos distintos 
elementos, y la presentacion de las altemativas bajo siglas mnemotecnicas. 

Las licencias CC han pasado, al momento de edicion del presente material, 
por cuatro versiones mayores, que han ido corrigiendo defectos en el lenguaje 
legal, y agregando o clarificando conceptos. Las opciones de las licencias CC 
son:^ 

CCO (Dominio Publico) La rigidez del convenio de Bema hace muy dificil en 
la mayor parte de las jurisdicciones el liberar una obra renunciando ex- 
presamente todos los derechos patrimoniales que conlleva. 

La licencia cero o dedicacion al dominio publico explicita esta renuncia ex- 
presa de derechos. 

BY (Atribucion) Todas las combinaciones de licencias CC a excepcion de CCO 
incluyen la clausula de atribucion: la obra puede emplearse para cual- 
quier fin, pero toda redistribucion debe reconocer el credito de manera 
adecuada, proporcionar un enlace a la licencia, e indicar si se han reali- 
zado cambios. Puede hacerlo en cualquier forma razonable, pero no de 
forma tal que sugiera que tiene el apoyo del licenciante o lo recibe por el 
uso que hace. 

SA (Compartir Igual) Si un usuario de la obra en cuestion decide mezclar, 
transformar o crear nuevo material a partir de ella, puede distribuir su 
contribucion siempre que utilice la misma licencia que la obra original. 
Esto es, la clausiila Compartir Igual le confiere un caracter Copyleft al li- 
cenciamiento elegido. 

NC (No Comercial) La obra puede ser utilizada, reprodudda o modificada se- 
gun lo permitido por los otros componentes elegidos de la licencia siem- 
pre y cuando esto no se considere o dirija hacia una ganancia comercial o 
monetaria. 

ND (No Derivadas) La obra puede ser redistribuida acorde con los otros com- 
ponentes elegidos de la licencia, pero debe serlo solo si no se afecta su 
integridad: no puede ser modificada sin autorizacion expresa del autor. 



^Parte del texto aqui presentado ha sido tornado del asistente para la elecci6n de licencias de 
Creative Commons; dicho texto esti Ucenciado bajo im esquema cc-by (atribuci6n) 4.0. 
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Las licencias CC han sido empleadas para todo tipo de creaciones: libros, 
miisica, peliculas, artes plasticas — incluso, si bien no era su fin original, para 
licenciamiento de software. Su gran exito estiba no solo en su uso, sino en que 
han llevado la nocion del licenciamiento permisivo y de las obras culturales 
libres a una gran cantidad de creadores que, sin CC, probablemente habrian 
publicado sus creaciones bajo la tradicional modalidad todos los derechos reser- 
vados. 

Creative Commons y las obras culturales libres 

No todas las licencias CC califican de obras culturales libres: en 2005, Benja- 
min Mako Hill explore el paralelismo entre CC y el movimiento del software 
libre en su texto Towards a standard of freedom: Creative commons and the free soft- 
ware movement; este trabajo sirvio como semilla para la definicion de Obras cul- 
turales libres, publicada en 2006. De forma paralela a las cuatro libertades del 
software, esta definicion acepta como obras libres a aquellas que garantizan: 

■ La libertad de usar el trabajo y disfrutar de los beneficios de su uso. 

■ La libertad de estudiar el trabajo y aplicar el conocimiento que pueda 
adquirirse de el. 

■ La libertad de hacer y redistribmr copias, totales o parciales, de la infor- 
macion o expresion. 

■ La libertad de hacer cambios y mejoras, y distribuir obras derivadas. 

De las opciones de licenciamiento CC, las que estan aprobados como obras 
culturales libres son CCO (dominio publico), BY (atribucion) y SA (compartir 
igual). Las variedades NC (no comercial) y ND (no derivadas), si bien permi- 
tenuTia mayor divulgacion y circulacion de la obra, restringen demasiado la 
apropiacion que puede realizar un usuario, por lo que no constituyen obras 
culturales libres. 

A.3. El licenciamiento empleado para la presente 
obra 

Los autores de este libro buscaron contribuir con material de calidad libre- 
mente apropiable y reutilizable para la ensenanza superior en paises hispa- 
noparlantes. Para lograr este fin, todo el material contenido en el libro (texto, 
codigo fuente e imagenes) esta licenciado bajo Creative Commons Atribucion 4.0 
Internacional (CC by 4.0),^ salvo si se menciona expHcitamente de otra manera. 



*https://creativecominons.org/licenses/by/4.0/deed.es 
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Esto significa que el usuario es libre para: 

■ Compartir — copiar y redistribuir el material en cualquier medio o forma- 
te, y mediante cualquier mecanismo. 

■ Adaptar — remezclar, transformar y crear a partir del material. 

■ Para cualquier proposito, incluso comercialmente. 

■ El licenciante no puede revocar estas libertades en tanto usted siga los 
terminos de la licencia. 

Bajo los siguientes terminos: 

■ Atribucion — Se debe reconocer el credito de una obra de manera ade- 
cuada, proporcionar un enlace a la licencia, e indicar si se han realizado 
cambios. Puede hacerse en cualquier forma razonable, pero no de mane- 
ra tal que sugiera que tiene el apoyo del licenciante o lo recibe por el uso 
que hace. 

■ Compartirlgual — si se mezcla, transforma o crea nuevo material a partir 
de esta obra, se podra distribuir su contribucion siempre que utilice la 
misma licencia que la obra original. 

No hay restricciones adicionales — usted no puede aplicar terminos legales 
ni medidas tecnologicas que restrinjan legalmente a otros hacer cualquier uso 
permitido por la licencia. 

A.4. Lecturas relacionadas 

■ The GNU Manifesto 

https : / / www . gnu .org/ gnu /manifesto . html 
Richard Stallman (1985); Dr. Dobb's Journal 

■ GNU General Public License version 3 
https : // gnu . org /licenses/ gpl. html 
Free Software Foundation (2007) 

■ The Evolution of the Unix Time-sharing System 

http : / /cm. bell- labs . com/ cm/ cs / who/ dmr /hist . html 
Dennis Ritchie, Language Design and Programming Methodology con- 
ference; Sydney, Australia, 1979. 
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■ GPL, BSD, and NetBSD - why the *gpl* rocketed Linux to success 
http: //www. dwheeler . com/blog/2 00 6/0 9/01/ 

David A. Wheeler (2006) 

■ The Grumpy Editor's guide to free documentation licenses 

https : //Iwn . net /Articles/108250/ 
Jonathan Corbet (2004); Liniix Weekly News 

■ GNU Free Documentation License version 1.3 
https : / /gnu . org/licenses/ f dl . html 
Free Software Foundation (2008) 

■ Construccion Colaborativa del Conocimiento 
http : // seminario . edusol . info/ 
Gunnar Wolf, Alejandro Miranda (2011) 

■ Towards a Standard of Freedom: Creative Commons and the Free Software Mo- 
vement 

http : / / www . advogato . org/ article/ 851 . html 
Benjamin Mako HiU (2005) 

■ Obras culturales libres 

http: / /f reedomdef ined . org/Def inition/Es 

Freedom Defined (2006) 



Apendice B 

Virtualizacion 



B.l. Introduccion 

La virtualizacion no es un concepto nuevo. Sin embargo, tras largos anos de 
estar relegado a un segundo piano, en la actualidad se torna fundamental en re- 
ferenda a los sistemas operatives, particularmente en papel de servidores. Este 
tema se abordara de momento desde un punto de vista mas bien descriptivo, 
y posteriormente se profundizara en algunos de sus asepectos. 

En primer termino, es importante aclarar que el concepto de virtualizacion 
no se refiere a una unica tecnologia o metodologia, es un termino que agrupa 
a muy distintas tecnologias que hay -de diversas formas- desde hace decadas. 
Cada una de ellas tiene su lugar, con diferentes usos y propositos, algunos de 
los cuales se usan de forma transparente para el usuario promedio. 

Del mismo modo, aunque se abordaran diversas tecnologias que pueden 
clasificarse como virtualizacion, la llnea divisoria entre cada una de ellas no 
siempre es clara. Una implementacion especifica puede caer en mas de ima 
categorla, o puede ir migrando naturaLmente de un tipo hacia otro. 

En escala general, virtualizar consiste en proveer algo que no esta ahi, aun- 
que parezca estarlo. Mas especificamente, presentar a un sistema elementos 
que se comporten de la misma forma que un componente fisico (hardware), 
sin que exista en realidad — un acto de ilusionismo o de magia, en el cual se 
busca presentar el elemento de forma tan convincente que la ilusion se man- 
tenga tanto como sea posible.^ 

La naturaleza de dichos elementos, y el como se implementan, dependen 
del tipo de virtualizacion. 



^Una aproximacion inicial a este concepto puede ser un archive con la imagen de un disco en 
formato ISO: mediante determinados mecanismos, es posible "enganar" a un sistema operative de 
forma que "piense" que al acceder al archivo ISO estd efectivamente leyendo im CD o DVD de xma 
imidad que no existe fisicamente. 
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Para casi todos los casos que se presentan, se emplearan los siguientes ter- 
minos: 

Anfitrion El hardware o sistema red, que ofrece el mecanismo de virtualiza- 
cion. En ingles se le denomina host. 

Huesped El sistema o las aplicaciones que se ejecutan en el entomo virtuali- 
zado. En ingles se les denomina guest. 

B.2. Emulacion 

La tecnica de virtualizacion mas sencilla, y que hace mas tiempo tienen las 
computadoras personales, es la emulacion. Emular consiste en implementar 
en software algo que se presente como el hardware de tm sistema de compute 
completo, tipicamente de una arquitectura hardware distinta a la del anfitrion 
(la arquitectura nativa)?- El emulador puede ser visto (de ima forma tremenda- 
mente simplificada) como una lista de equivalencias, de cada una de las ins- 
trucciones en la arquitectura huesped a la arquitectura del sistema anfitrion. 

Vale la pena recalcar que una emulacion no se limita con traducir del len- 
guaje y la estructura de un procesador a otro — para que una computadora 
pueda ser utilizada, requiere de una serie de chips de apoyo, desde los contro- 
ladores de cada uno de los buses hasta los perifericos basicos (teclado, video). 
Casi todas las emulaciones incluiran un paso mas alia: los perifericos mismos 
(discos, interfaces de red, puertos). Todo esto tiene que ser implementado por 
el emulador. 

Resulta obvio que emular im sistema completo es altamente ineficiente. Los 
sistemas huespedes resultantes tipicamente tendran ujn. rendimiento cientos o 
miles de veces menor al del anfitrion. 

Ahora bien, ^que pasa cuando hay dos arquitecturas de computo que em- 
plean el mismo procesador? Este caso fue relativamente comun en la decada de 
los ochenta y noventa; si bien en general las computadoras de 8 bits no tenian 
el poder de computo necesario para implementar la emulacion de arquitectu- 
ras similares, al aparecer tres Imeas de computadoras basadas en el CPU Mo- 
torola 68000 (Apple Macintosh, Atari ST y Commodore Amiga), diferenciadas 
prindpalmente por sus chipsets, aparecieron emuladores que permitian ejecu- 
tar programas de ima Imea en la otra, practicamente a la misma velocidad que 
en el sistema nativo. 

Hoy en dia, la emulacion se emplea para hacer desarrollos cruzados, mas que 
para emplear software ya escrito y compilado. La mayor parte de la emulacion 
tradicional se emplea para el desarrollo de software. Hoy en dia, la mayor parte 

^ A lo largo de esta discusion, se hara referenda a la arquitectura hardware como al juego de ins- 
trucciones que puede ejecutar nativamente im procesador. Por ejemplo, un procesador x86 modemo 
puede ejecutar nativamente c6digo 1386 y x86_64, pero no ARM. 
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de las computadoras vendidas son sistemas embebidos^ o dispositivos movi- 
les, que hacen imposible (o, por lo menos, muy dificil) desarroUar software 
directamente en ellos. Los programadores desarroUan en equipos de escrito- 
rio, ejecutan entornos de prueba en emuladores del equipo destino. A pesar 
del costo computacional de realizar la emulacion, la diferencia de velocidad 
entre los eqmpo de escritorio de gama alta y los embebidos permiten que fre- 
cuentemente la velocidad del emulador sea muy similar -incluso superior- a 
la del hardware emulado. 

B.2.1. Emulando arquitecturas inexistentes 

Pero la emulacion no se limita a hardware existente, y no solo se emplea 
por la comodidad de no depender de la velocidad de equipos especificos. Es 
posible crear emuladores para arquitecturas que nunca han sido implementadas 
en hardware real. 

Esta idea viene de los setenta, cuando comenzo la explosion de arquitec- 
turas. La Universidad de California en San Diego propuso una arquitectura 
Uamada p-system, o sistema-p, la cual definirfa una serie de instrucciones a las 
que hoy se clasificarlan como codigo intermedio o bytecode, a ser ejecutado en 
una mdquina-p, o p-machine. El lenguaje base para este sistema fue el Pascal, 
mismo que fue adoptado muy ampliamente de manera principal en entornos 
academicos a lo largo de los setenta y ochenta por su limpieza y claridad es- 
tructural. Todo programa compilado para ejecutarse en un sistema-p ejecutaria 
sin modificaciones en cualquier arquitectura hardware que lo implementara. 

Los sistemas-p gozaron de relativa popularidad hasta mediados de los 
ochenta, logrando implementaciones para las arquitecturas de microcompu- 
tadoras mas populares — el MOS 6502, el Zilog z80 y el Intel 80x86. 

Hay una diferencia muy importante entre la emulacion de ujna arquitectura 
real y la de una inexistente: emular una computadora entera requiere imple- 
mentar no solo las instrucciones de su procesador, sino que todos los chips de 
apoyo, jincluso hay que convertir la entrada del teclado en las interrupciones 
que generarfa un controlador de teclado! Emular una arquitectura hipotetica 
permite manejar diversos componentes de forma abstracta, y tambien definir 
estructuras de mucho mas alto nivel que las que se encuentran implementa- 
das en hardware. Por ejemplo, si bien resultarfa impractico crear como tipo 
de datos nativo para una arquitectura en hardware una abstraccion como las 
cadenas de caracteres, estas si existen como ciudadanos de primera clase en casi 
todas las arquitecturas meramente virtuales. 

Esta idea ha sido ampliamente adoptada y forma parte de la vida diaria. En 
la decada de los noventa. Sun Microsystems desarrollo e impulse la arquitectura 

^Computadoras pequenas, limitadas en recursos, y tipicamente carentes de una interfaz usuario 
— desde puntos de acceso y ruteadores hasta los controladores de cdmaras, equipos de sonido, 
autom6viles, y un largufsimo etcetera. 
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Java, actualizando la idea de las mdquinas-p a los paradigmas de desarrollo que 
aparecieron a lo largo de 20 anos, y dado que el computo habia dejado de ser 
un campo especializado y escaso para masificarse, invirtiendo fuertemente en 
publicidad para impulsar su adopcion. 

Uno de los slogans que mejor describen la intencion de Sun fue WORA: Write 
Once, Run Anywhere (escribe una vez, ejecuta donde sea). El equivalente a una 
mdquina-p (rebautizada como JVM: Mdquina Virtual Java) se implementarla para 
las arquitecturas hardware mas limitadas y mas poderosas. Sun creo tambien el 
lenguaje Java, disenado para aprovechar la arquitectura de la JVM, enfatizando 
en la orientacion a objetos e incorporando facilidades miilti-hilos. Al dia de hoy 
hay distintas implementaciones de la JVM, de diferentes empresas y grupos de 
desarroUadores y con diversos focos de especializacion, pero todas ellas deben 
poder ejecutar el hytecode de Java. 

A principios de los anos 2000, y como resultado del litigio con Sun que 
imposibilito a Microsoft a desarroUar extensiones propietarias a Java (esto es, 
desarrollar maquinas virtuales que se salieran del estandar de la JVM), Micro- 
soft desarrollo la arquitectura .net. Su principal aporte en este campo es la 
separacion definitiva entre lenguaje de desarrollo y codigo intermedio produ- 
cido: la maquina virtual de .NET esta centrada en el CLi {Common Language 
Infrastructure, Infraestructura de Lenguajes Comunes), compuesta a su vez por 
el CIL {Common Intermediate Language, Lenguaje Intermedio Comiin, que es la 
especificacion del hytecode o codigo intermedio) y el CLR {Common Language 
Runtime, Ejecutor del Lenguaje Comiin, que es la implementacion de la maqui- 
na virtual sob re la arquitectura hardware nativa). 

En los anos noventa, una de las principales criticas a Java (la cual podria 
ampliarse hacia cualqmer otra plataforma comparable) era el desperdicio de 
recursos de procesamiento al tener que traducir, una y otra vez, el codigo in- 
termedio para su ejecucion en el procesador. Hacia el 2010, el panorama habia 
cambiado fuertemente. Hoy en dia las maquinas virtuales implementan varias 
tecnicas para reducir el tiempo que se desperdicia emulando: 

Traduccion dinamica Compilacion parcial del codigo a ejecutar a formatos na- 
tivos, de modo que solo la primera vez que se ejecuta el codigo interme- 
dio tiene que ser traducido. 

Traduccion predictiva Anticipar cuales seran las siguientes secciones de co- 
digo que tendran que ser ejecutadas para, paralelamente al avance del 
programa, traducirlas a codigo nativo de forma preventiva. 

Compilacion justo a tiempo (jit) Almacenar copia del codigo ya traducido 
de un programa, de modo que no tenga que hacerse ni siquiera en ca- 
da ejecucion, sino que solo una vez en la vida de la maquina virtual. 

Mediante estas estrategias, el rendimiento de las arquitecturas emuladas es 
ya practicamente identico al del codigo compilado nativamente. 
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Figura B.l: Arquitectura de la infraestructura de lenguajes comunes (CLi) de .NET 
(imagen de la Wikipedia: Common Language Infrastructure). 



B.2.2. De lo abstracto a lo concreto 

Si bien las arquitecturas de maquinas virtuales planteadas en el apartado 
anterior se plantearon directamente para no ser implementadas en hardware, 
el exito comercial de la plataforma llevo a crear una llnea de chips que ejecu- 
tara nativamente codigo intermedio Java, con lo cual podrlan ahorrarse pasos y 
obtener mejor rendimiento de los sistemas destrno. Sun definio la arquitectura 
MAJC {Microprocessor Architecture for Java Computing, arquitectura de micropro- 
cesadores para el computo con Java) en la segunda mitad de los noventa, e 
incluso produjo un chip de esta arquitectura, el MAJC 5200. 

La arquitectura MAJC introdujo conceptos importantes que han sido reto- 
mados para el diseno de procesadores posteriores, pero la complejidad llevo a 
un rendimiento deficiente, y el chip resulto un fracaso comercial. 

Es importante mencionar otra aproximacion. Transitando en el sentido in- 
verso al de Sun con MAJC, Transmeta, una empresa hasta entonces desconocida, 
anuncio en el 2000 el procesador Crusoe, orientado al mercado de bajo consu- 
me energetico. Este procesador, en vez de implementar una arquitectura ya 
existente para entrar a un mercado ya muy competido y duiamico, centro su 
oferta en que Crusoe trabajarla mano a mano con un modulo llamado CMS 
{Code Morphing Software, Software de Transformacion de Codigo), siendo asl 
el primer procesador disenado para emular por hardware a otras arquitecturas. 
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Crusoe fue lanzado al mercado con el CMS para la arquitectura x86 de Intel, 
y efectivamente, la emulacion era completamente transparente al usuario.^ El 
procesador mismo, ademas, no implementaba algunas caracteristicas que hoy 
se consideran fundamentales, como una unidad de manejo de memoria, dado 
que eso podia ser implementado por software en el CMS. Separando de esta 
manera las caracteristicas complejas a una segunda capa, podian mantenerse 
mas bajos tanto el numero de transistores (y, por tanto, el gasto energetico) y 
los costos de produccion. 

La segunda generacion de chips Transmeta (Efficeon) estaba basada en una 
arquitectura muy distinta, buscando un rendrmiento mejorado. Pero, gracias al 
CMS, esto resulta imperceptible al usuario. 

A pesar de estas ideas interesantes y novedosas, Transmeta no pudo man- 
tener el dinamismo necesario para despegar, y ceso sus operaciones en 2009. 

B.2.3. ^Emulacion o simulacion? 

Una pregunta frecuente que se presenta al hablar de este tema es acerca 
de la diferencia entre la emulacion y la simulacion. Todos los casos presentados 
anteriormente se tratan de emulacion. 

Emular significa imitar las acciones de otro, procurando igualarlas e incluso ex- 
cederlas (Diccionario de la Real Academia Espanola, 23" edicion). Esto significa 
que im emulador reproduce todos los procesos intemos que realizaria el sis- 
tema nativo, y busca cubrir todos los comportamientos respectivos implemen- 
tando los mismos mecanismos. 

Simular, por otra parte, y segun este mismo diccionario, significa represen- 
tar algo, fingiendo o imitando to que no es. Un sistema simulador simula o finge 
las areas de determinado sistema que interesan al usuario; puede emplear da- 
tos precargados para generar ciertas respuestas, obviando los procesos que los 
generarfan. 

A diferencia de los ejemplos presentados a lo largo de esta seccion, que lie- 
van a ejecutar software arbitrario para la plataforma destino buscando ideal- 
mente que estos no detecten siquiera una diferencia en comportamiento, un 
simulador puede presentar mucho mayor detalle en determinadas areas, pero 
no realiza las funciones sustantivas del sistema simulado. Por ejemplo, es muy 
comiin (incluso para el entrenamiento de pilotos reales) el uso de simuladores 
de vuelo; estos programas pueden representar una cabina equivalente a la de 
\m avion real, con todos sus morutores y controles, pero nadie esperaria que lo 
trasladen de im lugar a otro. Muchos de los lectores habran empleado software 

^Empleando Transmeta, se podian observar ciertos comportamientos curiosos: por ejemplo, 
dado el amplio espacio de cache que implementaba el CMS, el codigo ejecutable se mantenia ya 
traduddo listo para el procesador. Por tal motivo, la primera vez que se ejecutaba una funcibn era 
notablemente mas lenta que en ejecuciones posteriores. Sin embargo, si bien estas diferencias son 
medibles y no deben escapar a la vista de quien estd analizando a conciencia estos procesadores, 
resultaban invisibles para el usuario final. 
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de simulacion de circuitos electronicos, que permiten el diseno y pruebas sim- 
ples de circuitos, pero no esperaran que sunular en la computadora un nucleo 
de ferrita rodeado por una bobina resulte en un receptor de radio. 

B.3. Virtualizacion asistida por hardware 

Actualmente se usa la virtualizacion como una herramienta para la consoli- 
dacion de servicios, de gran ayuda para los administradores de sistemas. Este 
uso se refiere principalmente a lo que se presentara en este apartado, asi como 
en las secciones B.4 {Paravirtualizacion) y B.5 (Contenedores). Y si bien este zum- 
bido de la virtualizacion se ha producido mayormente a partir del 2006-2007, no 
se trata de tecnologias o ideas novedosas — pueden encontrarse ejemplos des- 
de finales de los sesenta. Hasta hace alguxios anos, sin embargo, se mantenia 
dentro del ambito de los servidores en gran escala, fuera del alcance de la ma- 
yor parte de los usuarios. Es necesario estudiar la genesis de esta herramienta, 
para poder comprender mejor como opera y se implementa. 

En 1964, IBM creo la primer familia de computadoras, la serie 360. Presentaron 
la entonces novedosa idea de que una organizacion podia adquirir un mode- 
lo sencillo y, si sus necesidades se ajustaban al modelo de compute, podrian 
migrar facilmente hacia otros mas poderosos, dado que tendrian compatibilidad 
binaria. 

Uno de los modelos de esta familia fue la S-360-67, con la caracterlstica 
distintiva de ser la unica de la serie 360 en ofrecer una unidad de manejo de 
memoria (mmu), con lo cual permitfa la reubicacion de programas en memoria. 
Esto, sin embargo, creaba un problema: el software desarroUado para los equi- 
pos mas pequenos de la familia estaba creado bajo un paradigma de usuario 
linico, y si bien podrfa ser ejecutado en este modelo, eso llevarfa a un desper- 
dicio de recursos (dado que el modelo 67 tenia todo lo necesario para operar 
en modo multitarea). 

La respuesta de IBM fue muy ingeniosa: desarrollar un sistema operative 
mfnimo, CP {Control Program, Programa de Control) con el linico proposito de 
crear y gestionar mdquinas virtuales en del hardware S/360-67, dentro de cada 
una de las cuales pudiera ejecutarse sin requerir modificaciones un sistema opera- 
tive estandar de la serie 360. Entre los varies sistemas operatives dispenibles 
para la S/360, el que mas frecuentemente se utilize fue el *cms*p un sistema 
sencillo, interactive y monousuario. La combinacion CP /CMS proporcionaba 
un sistema operative multiusuarie, con plena preteccion entre procesos, y con 
compatibilidad con los modelos mas modestos de la serie 360. 

Aiin despues de la vida litil de la serie 360 original, IBM mantuve compati- 

^Originalmente, las siglas CMS eran por el Cambridge Monitor System, por haber sido desarroUa- 
do en la divisi6n de mvestigaci6n de IBM en Cambridge, pero posteriormente fue renombrado a 
Conversational Monitor System, Sistema de Monitoreo Conversacional. 
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bilidad con este modelo hacia la serie 370, e incluso hoy, 50 anos mas tarde, se 
encuentra atin como z/VM zfVbA en la linea de Sistemas z. 

Vale la pena mencionar que tanto CP como CMS fueron distribuidos desde 
el principio de forma consistente con lo que en la actualidad se conoce co- 
mo software libre: IBM los distribula en fuentes, con permiso de modificacion y 
redistribucion, y sus diferentes usuarios fueron enviando las mejoras que rea- 
lizaban de vuelta a IBM, de modo que hoy incorpora el trabajo de 50 ahos de 
desarrolladores. 

B,3.1. El hipervisor 

El modelo CP/ CMS Ueva a una separacion bastante limpia entre un mul- 
tiplexador de hardware (CP) y el sistema operativo propiamente dicho (CMS). Y 
si bien la dupla puede ser vista como un solo sistema operativo, conforme se 
fueron ejecutando en maquinas virtuales sistemas operativos mas complejos 
se hizo claro que el CP tendria que ser otra cosa. Partiendo del concepto de que 
el sistema operativo es el supervisor de la actividad de los usuarios, yendo un 
paso mas hacia arriba, se fue popularizando el nombre de hipervisor para el pro- 
grama que administra y virtualiza a los supervisores. Algimas caracteristicas 
primarias que definen que es ujn hipervisor son: 

■ Es linicamente un micro-sistema operativo, dado que no cubre muchas 
de las areas clasicas ni presenta las interfaces abstractas al usuario fi- 
nal — sistemas de archivos, mecanismos de comunicacion entre procesos, 
gestion de memoria virtual, evasion de bloqueos, etcetera. 

■ Se limita a gestionar bloques de memoria fisica contiguos y fijos, asigna- 
cion de dispositivos y poco mas que eso. 

■ Normalmente no tiene una interfaz usuario directa, sino que es adminis- 
trado por medio de llamadas privilegiadas desde alguno de los sistemas 
operativos huesped. 

Estas Imeas se han ido haciendo borrosas con el tiempo. Ahora, por ejem- 
plo, muchos hipervisores entienden a los sistemas de archivos, permitiendo 
que los espacios de aLmacenamiento ofrecidos a sus sistemas operativos hues- 
ped sean simples archivos para el sistema anfitrion (y no particiones o dis- 
positivos enteros). Algunos hipervisores, como KVM bajo Linux se presentan 
integrados como un componente mas de un sistema operativo estandar. 

B.3.2. Virtualizacion asistida por hardware en x86 

Hasta alrededor del ano 2005, la virtualizacion no se mencionaba muy fre- 
cuentemente. Si bien habia hardware virtualizable 40 anos atras, era bastante 
especializado — y caro. Ese ano, Intel saco al mercado los procesadores con las 
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extensiones necesarias para la virtualizacion, bajo el nombre Vanderpool Techno- 
logy (o VT/x). A1 ano siguiente, AMD hizo lo propio, denominandolas extensio- 
nes Pactfica. Ahora casi todas las computadoras de escritorio de rango medio- 
alto tienen el sopote necesario para llevar a cabo virtualizacion asistida por 
hardware. Y si bien en un principio el tema tardo en tomar traccion, llevo a un 
replanteamiento completo de la metodologia de trabajo tanto de administra- 
dores de sistemas como de programadores. 

En contraste con las arquitecturas disenadas desde un principio para la vir- 
tualizacion, los usuarios de computadoras personales (inclusive cuando estas 
son servidores en centres de datos, siguen estando basadadas en la misma ar- 
quitectura basica) se enfrentan a una mayor variedad de dispositivos para todo 
tipo de tareas.^ Si bien la virtualizacion permite aparentar varias computadoras 
distintas ejecutando sobre el mismo procesador, esta no incluye los dispositi- 
vos. Al presentarse una maquina virtual, el sistema anfitrion esta casi siempre^ 
emiilando hardware. Claro esta, lo mas frecuente es que el hipervisor ofrezca 
a los huespedes la emulacion de dispositivos relativamente viejos y simples.^ 
Esto no significa que esten limitados a las prestaciones del equipo emulado 
(por ejemplo, a los 10 Mbps para los que estaba disenada una tarjeta de red 
NE2000), sino que la interfaz del nucleo para enviar datos a dicho dispositivo 
es una sencUla y que ha sido empleada tanto tiempo que presenta muy poca 
inestabilidad. 

Y este ultimo pimto permite vin acercamiento mayor a ima de las venta- 
jas que ofrecen los sistemas operatives virtualizados — ^la estabilidad. Los con- 
troladores de dispositivos provistos por fabricante han sido responsabilizados 
una y otra vez, y con justa razon, de la inestabilidad de los sistemas operatives 
de escritorio. En particular, son en buena medida culpables de la fama de ines- 
tabilidad que obtuvo Windows. Los fabricantes de hardware no siempre go- 
zan de suficiente conocimiento acerca del sistema operative como para escribir 
centreladeres suficientemente seguros y de calidad, y por muchos anos, los sis- 
temas Windows no implementaban mayor verificacion al comportamiento de 
los controladores — que, siendo un sistema monoHtico, eran codigo ejecutado 
con privilegios de nucleo. 

Al emplear el sistema operative huesped linicamente controladores amplia- 
mente probados y estabilizados a lo largo de muchos anos, la estabilidad que 
ofrece una maquina virtualizada muchas veces supera a la que obtendria ejecu- 
tandose de forma nativa. Claro, el conjunto de maquinas virtuales que se ejecu- 

*Una descripcion completa de la complejidad a la que debe enfrentarse un hipervisor bajo ar- 
quitectura x86 excede con mucho el ambito del presente texto; se sugiere a los lectores interesados 
referirse al excelente artlculo de Bugnion et al. (2012) detallando la implementacion de VMWare. 

''Hay mecanismos para reservar y dirigir un dispositivo fisico existente a una maquina virtual 
especifica, pero hacerlo implica que este dispositivo no serd multiplexado hacia las demis mdquinas 
virtuales que se ejecuten paralelamente. 

^Por ejemplo, KVM bajo Linux emula tarjetas de red tipo NE2000, tarjetas de sonido tipo Sound- 
blasterl6 y tarjetas de video Cirrus Logic, todos ellos de la dtoda de los noventa. 
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te dentro de un sistema anfitrion sigue siendo susceptible a cualquier inestabi- 
lidad del mismo sistema anfitrion, sin embargo, es mucho menos probable que 
un programa mal disenado logre congelarse esperando respuesta del hardware 
(emulado), y mucho menos afectar a los demas huespedes. 

B.4. Paravirtualizacion 

La virtualizacion asistida por hardware, por conveniente que resulte, sigue 
presentando algunas desventajas: 

■ No todos los procesadores cuentan con las extensiones de virtualizacion. 
Si bien cada vez es mas comiin encontrarlas, es aiin en Ifneas generales 
\m factor de diferenciacion entre las lineas economicas y de lujo. 

■ La capa de emulacion, si bien es delgada, conlleva un cierto peso. 

■ Si bien es posible virtualizar arquitecturas como la x86, hay muchas otras 
para las cuales no se tienen las extensiones hardware necesarias. 

La paravirtualizacion, o virtualizacion asistida por el sistema operativo, parte de 
un planteamiento distinto: en vez de enganar al sistema operativo para que fun- 
cione sobre im sistema que parece real pero no lo es, la paravirtualizacion busca 
hacerlo con pleno conocimiento y cooperacion por parte de los sistemas huespedes. 
Esto es, la paravirtualizacion consiste en alojar sistemas operativos huesped 
que, a sabiendas de que estan ejecutando en hardware virtualizado, no hacen 
llamadas directas a hardware sino que las traducen a llamadas al sistema operati- 
vo anfitrion. 

Vale la pena reiterar en este punto: los sistemas operativos huesped bajo un 
entorno paravirtualizado saben que no estan ejecutando sobre hardware real, 
por lo que en vez de enviar las instrucciones que controlen al hardware, envlan 
llamadas al sistema a su hipervisor. Hasta derto punto, el proceso de adecua- 
cion de un sistema para que permita ser paravirtualizado puede ser equivalen- 
te a adecuar al sistema operativo para que ejecute en una arquitectura nueva 
— muy parecida a la del hardware real, si, pero con diferencias ftindamentales 
en aspectos profundos. 

Y si bien ya se explico en la seccion anterior que la virtualizacion puede 
ajoidar a presentar un sistema idealizado que reduzca la inestabilidad en un 
sistema operativo, al hablar de paravirtualizacion este beneficio naturalmen- 
te crece: los controladores de hardware sencillos y bien comprendidos que se 
usaban para gestionar los dispositivos emulados se convierten casi en simples 
pasarelas de llamadas al sistema, brindando ademas de una sobrecarga mini- 
ma, aim mayor estabilidad por simplicidad del codigo. 
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B.4.1. Paravirtualizacion y software libre 

La paravirtualizacion resulta muy atractiva, presentarido muy obvias ven- 
tajas. Pero a pesar de que es posible emplearla en cualquier arquitectura hard- 
ware, algunas veces no lo es. 

Como se menciono anteriormente, incorporar dentro de un sistema opera- 
tive el soporte para una arquitectura de paravirtualizacion es casi equivalente 
a traducirlo a una nueva arquitectura hardware. Para que los autores de un 
entomo que implemente paravirtualizacion logren que un sistema operative 
nuevo pueda ser ejecutado en su arquitectura, deben poder manipular y mo- 
dificar su codigo fuente: de otra manera, ^como se le podrfa adecuar para que 
supiera desenvolverse en un entomo no native? 

El proyecto de gestion de virtualizacion y paravirtualizacion Xen nacio co- 
mo un proyecto academico de la Universidad de Cambridge, presentando su 
version 1.x mediante un artlculo en 2003 (Xen and the Art of Virtualization). 
Este articulo presenta su experiencia paravirtualizando a una version entonces 
actual de Linux y de Windows. Sin embargo, Xen solo pudo ser empleado por 
muchos anos como plataforma de paravirtualizacion de Linux porque, dado 
que la adaptacion de Windows se realize bajo los terminos del Academic Licen- 
sing Program, que permitfa a los investigadores acceso y modificacion al codigo 
fuente, pero no su redistribucion — la version paravirtualizable de Windows 
XP fue desarrollada, pero no puede distribuirse fuera de los participantes de 
dicho programa de licenciamiento. 

En tanto, el trabajo necesario para lograr la paravirtualizacion de un sis- 
tema operative libre, come Linux, FreeBSD u etres, puede ser libremente re- 
distribmdo. No solo eso, sino que el esfuerzo de realizar la adaptacion pudo 
compartirse entre desarrolladores de todo el mimdo, dado que esta entonces 
novedosa tecnologia resultaba de gran interes. 

B.4.2. Paravirtualizacion de dispositivos 

Las ideas derivadas de la paravirtualizacion pueden emplearse tambien ba- 
jo entornos basados en virtualizacion plena: si el sistema operative esta estruc- 
turado de una forma modular (sin que esto necesariamente signifique que es 
un sistema microkernel, sino que permita la carga dinamica de controladores o 
drivers para el hardware, como practicamente la totalidad de sistemas dispo- 
ndbles comerciahnente hoy en dfa), no hace falta modificar al sistema operati- 
ve complete para gozar de los beneficios de la paravirtualizacion en algimas 
areas. 

De esta manera, si bien es posible ejecutar un sistema operative sin modifi- 
caciones que espera ser ejecutado en hardware real, los dispositivos que tfpica- 
mente generan mas actividad de entrada y salida^ pueden ser atendidos por 
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drivers paravirtuales. For supuesto, varios aspectos que son parte del nucleo 
duro del sistema, como la administracion de memoria o el manejo de interrup- 
ciones (incluyendo el temporizador) tendran que seguirse manejando median- 
te una emulacion, aunque mucho mas delgada. 

Segiin mediciones empmcas realizadas en 2007 por Qumranet (quienes li- 
derearon el desarroUo del m6dulo de virtualizaci6n asistido por hardware KVM 
en Linux), las clases de dispositivos virtio y pv resultaron entre 5 y 10 veces 
mas rapidas que la emulacion de dispositivos reales. 

Mediante esta estrategia es posible ejecutar sistemas operativos propieta- 
rios, como los de la familia Windows, con buena parte de las ventajas de la 
paravirtualizacion, sobre entornos de virtualizacion asistida por hardware. 

B.5. Contenedores 

Una estrategia completamente distinta para la creacion de maquinas vir- 
tuales es la de contenedores. A diferencia de emulacion, virtualizacion asistida 
por hardware y paravirtualizacion, al emplear contenedores solo se ejecuta un 
sistema operative, que es el mismo para los sistemas anfitrion y huesped. El an- 
fitrion implementara \ma serie de medidas para aumentar el grado de separacion 
que mantiene entre procesos, agregando la nocion de contextos o grupos que 
se describiran en breve. Dado que el sistema operativo es el unico autorizado 
para tener acceso directo al hardware, no hace falta ejecutar un hipervisor. 

Podria presentarse un simil: las tecnologias antes descritas de virtualiza- 
cion implementan hardware virtual para cada sistema operativo, mientras que 
los contenedores mas bien presentan \m sistema operativo virtual para el con- 
jimto de procesos que definen el comportamiento de cada maquina virtual 
— ^muchos autores presentan la virtualizacion por contenedores bajo el nom- 
bre virtualizacion a nivel sistema operativo. Y si bien el efecto a ojos del usuario 
puede ser comparable, este metodo mas que una multiplexacion de maquinas 
virtuales sobre hardware real opera mediante restricciones adicionales sobre 
los procesos de usuario. 

Al operar a un nivel mas alto, un contenedor presenta algiinas limitantes 
adicionales (principalmente, se pierde la flexibilidad de ejecutar sistemas ope- 
rativos distintos), pero obtiene tambien importantes ventajas. 

El desarrollo historico de los contenedores puede rastrearse a la Uamada 
al sistema chroot ( ) , que restringe la vision del sistema de archivos de un 
proceso a solo el directorio hacia el cual esta fue invocada.^'' Esto es, si dentro 
deunprocesoseinvoca chroot (' /usr/local' ) y posteriormente se le pide 

^"^La Uamada chr oot ( ) fue creada por Bill Joy en 1982 para ayudarse en el desarrollo del siste- 
ma Unix 4.2BSD. Joy buscaba probar los cambios que iba haciendo en los componentes en espacio 
de usuario del sistema sin modificar su sistema mvo y en producci6n, esto es, sin tener que re- 
instalar y reiniciar cada vez, y con esta Uamada le fue posible instalar los cambios dentro de un 
directorio especffico y probarlos como si fueran en la rafz. 
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abrir el archivo /boot . img, a pesar de que este indique una ruta absoluta, el 
archive que se abrira sera /usr/local/boot . img 

Ahora bien, chroot ( ) no es (ni busca ser) un verdadero aislamiento, so- 
lo proporciona un inicio^^ — pero conforme mas usuarios comenzaban a utili- 
zarlo para servicios en produccion, se hizo claro que resultaria litil ampliar la 
conveniencia de chroot ( ) a un verdadero aislamiento. 

El primer sistema en incorporar esta funcionalidad fue FreeBSD creando el 
subsistema Jails a partir de su version 4.0, del ano 2000. No tardaron mucho en 
aparecer implementaciones comparables en los distintos sistemas Unix. Hay 
incluso \m producto propietario, el Parallels Virtuozzo Containers, que imple- 
menta esta funcionalidad para sistemas Windows. 

Un punto importante a mencionar cuando se habla de contenedores es que 
se pierde buena parte de la universalidad mencionada en las secciones ante- 
riores. Si bien las diferentes implementaciones comparten principios basicos 
de operacion, la manera en que logran la separacion e incluso la nomenclatura 
que emplean difieren fuertemente. 

El nucleo del sistema crea un grupo para cada contenedor (tambien conocido 
como contexto de seguridad), aislandolos entre si por lo menos en las siguientes 
areas: 

Tablas de procesos Los procesos en un sistema Unix se presentan como un ar- 
bol, en cuya raiz esta siempre el proceso 1, init. Cada contenedor inicia 
su existencia ejecutando un init propio y enmascarando su identifica- 
dor de proceso real por el numero 1 . 

Senales, comunicacion entre procesos Ningiin proceso de im contenedor de- 
be poder interferir con la ejecucion de \mo en otro contenedor. El nucleo 
restringe toda comunicacion entre procesos, regiones de memoria com- 
partida y envfo de sefiales entre procesos de distintos grupos. 

Interfaces de red Varfa segiin cada sistema operative e implementacion, pero 
en lineas generales, cada contenedor tendra una interfaz de red con una 
direccion de acceso a medio (*mac*) distinta.^^ Claro esta, cada una de ellas 
recibira una diferente direccion IP, y el nucleo ruteara e incluso aplicara 
reglas de firewall entre ellas. 

Dispositivos de hardware Normalmente los sistemas huesped no tienen acce- 
so directo a ningiin dispositivo en hardware. En algunos casos, el acceso 
a dispositivos sera multiplexado y, en otros, un. dispositivo puede espe- 
cificarse por medio de su configuracion. Cabe mencionar que, dado que 
esta multiplexion no requiere emulacion, sino unicamente una cuidadosa 
planificacidn, no resulta tan oneroso como la emiilacion. 

^^Como referencia a por que no es un verdadero aislamiento, puede referirse al artlculo How to 
break out of a chrootO jail (Simes, 2002) 

^^Es comim referirse a las direcciones MAC como direcciones flsicas, sin embargo, todas las tar- 
jetas de red permiten configurar su direcci6n, por lo cual la apelacibn^'sica resulta engaflosa. 
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Limites en consumo de recursos Casi todas las implementaciones permiten 
asignar cotas maximas para el consumo de recursos compartidos, como 
espacio de memoria o disco o tiempo de CPU empleados por cada uno de 
los contenedores. 

Nombre del equipo Aiinque parezca trivial, el nombre con el que una compu- 

tadora se designa a st misma debe tambien ser aislado. Cada contenedor 
debe poder tener un nombre linico e independiente. 

Una de las principales caracteristicas que atrae a muchos administradores a 
elegir la virtualizacion por medio de contenedores es un consumo de recursos 
Optimo: bajo los demas metodos de virtualizacion (y, particularmente, al hablar 
de emulacion y de virtualizacion asistida por hardware), una maquina virtual 
siempre ocupara algunos recursos, asf este inactiva. El hipervisor tendra que 
estar notificando a los temporizadores, enviando los paquetes de red recibi- 
dos, etc. Bajo ujn. esquema de contenedores, una maquina virtual que no tiene 
trabajo se convierte sencillamente en un grupo de procesos dormidos, probables 
candidatos a ser paginados a disco. 

B.6. Ejercicios 

6.6.1. Preguntas de autoevaluacion 

1. En este capftulo se presentaron diversas tecnologfas para la virtualiza- 
cion: emulacion, virtualizacion asistida por hardware, paravirtualizacion 
y contenedores. Las cuatro categorfas tienen su lugar y casos de uso re- 
comendados. Elabore un cuadro comparativo, presentando las ventajas y 
desventajas relativas de cada categoria respecto a las demas. 

2. A continuacion se presentan varias afirmaciones. Evalue si cada una de 
ellas es verdadera o falsa, sustentando con argumentos su conclusion. 

■ La emulacion implica naturalmente implementar un interprete del 
codigo que fue originado para una arquitectura distinta. Este proce- 
so necesariamente tiene un alto costo en tiempo de computo, y una 
infraestructura basada en emulacion siempre sera por lo menos un 
orden de magnitud mas lenta que lo que resultaria de su ejecucion 
nativa. La popularizacion de la emulacion deriva, por tm lado, de la 
diferencia de poder de computo entre las arquitecturas de escritorio 
y las embebidas y, por el otro, de la converuencia de contar con codi- 
go que pueda ser transportado facilmente (write once, run anywhere). 

■ La Ley de Moore (presentada en la seccion 2.9.1) ha llevado a ima 
cada vez mayor integracion y ha llevado a que el desarrollo del 
computo por fin cruzara obligadamente por el miiltiprocesamiento. 
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el desarrollo de codigo paralelizable es mucho mas complejo para 
los programadores; casi todo el material de la presente obra deri- 
va del cuestionamiento de como compartir recursos entre procesos 
rivales. 

En este sentido, una de las grandes ventajas que ofrece la virtua- 
lizacion es que, al separar las aplicaciones en maquinas virtuales 
distintas, mantener \ma separacion de recursos se simplifica. Cada 
maquina virtual puede correr en ujn entomo monotarea, con la ilu- 
sion de recursos dedicados. 

3. De los recursos que administra un sistema operativo, algunos pueden 
ser facilmente compartidos, en tanto que otros requieren un uso exclusi- 
vo para cada una de las maquinas virtuales. ^Cuales entrarian en cada 
una de estas clases, que estrategia podria sugerir para compartir \m dis- 
positivo cuya naturaleza fuera de uso exclusivo? 

4. Identifique cual de las siguientes afirmaciones describe la principal dife- 
rencia entre la virtualizacion asistida por hardware y la paravirtualiza- 
cion 

a) La virtualizacion asistida por hardware requiere de electronica espe- 
cifica para ser empleada, mientras que la paravirtualizacion evaliia 
por software todas las instrucciones e intercepta las instrucciones 
"peligrosas", a cambio de un menor rendimiento. 

b) La virtualizacion permite ejecutar al sistema huesped sin modifi- 
caciones, como si fuera en ima computadora real, mientras que la 
paravirtualizacion requiere que este este preparado para ser virtua- 
lizado. 

c) Se efectua linicamente a nivel de dispositivos, mientras que la vir- 
tualizacion plena se aplica sobre del sistema completo. 

5. En el corazon de las arquitecturas de virtualizacion asistida por hardware 
encontraremos \m programa llamado hipervisor. Indique cuales de las si- 
guientes afirmaciones respecto a esta tecnologfa son verdaderas, y cuales 
falsas. Busque sustentarlo con ejemplos de sistemas existentes. 

a) Monitorea la actividad de los sistemas operativos. 

h) Se mantiene completamente invisible ante la perspectiva del sistema 
huesped. 

c) Es completamente transparente: un hipervisor debe poder correr 
otros dentro de si. 

d) Cubre alguxias de las tareas que realiza normalmente el sistema ope- 
rativo. 
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6.6.2. Temas de investigacion sugeridos 

Sistemas operatives minimos para la nube Al hablar de virtualizacion, sea 
asistida por hardware o paravirtualizacion, varias voces se han levan- 
tado, indicando que ejecutar un sistema operativo completo dentro de 
\ma maqiiina virtual es \m desperdicio de recuxsos. A fin de cuentas, si el 
sistema operativo tipico a correr dentro de una maquina virtual en el CP 
del S/360 de IBM, hace mas de 40 anos, era un sistema sencillo, interactivo 
y monousuario (CMS), ipor que no repetir la experiencia? 

Un ejemplo de sistema mlnimo fue presentado en septiembre de 2013: 

OSv. Este sistema busca no implementar los subsistemas innecesarios de 
un Linux tradicional, sino linicamente permitir la ejecucion de varios de 
los procesos mas comunes en una maquina virtual. Pueden buscar al res- 
pecto: 

■ Anundo en Slashdot: New operating system seeks to replace Linux 
in the cloud 

■ Presentacion del proyecto, del congreso CloudOpen 

■ Artlculo respecto al lanzamiento de OSv en The Register 

■ Deposito Git del codigo de OSv en GitHub. 

Algunos pimtos que podrian desarrollar: 

■ Que gana OSv y otros proyectos por el estilo, y que pierden. 

■ Como ha avanzado la adopcion de estas ideas. 

■ Que le agrega o qmta a la complejidad de la administracion de sis- 
temas. 

B.6.3. Lecturas relacionadas 

■ Bringing Virtualization to the x86 Architecture with the Original VMware 
Workstation 

https : //dl . acm. org /citation. cfm?doid=2382 553 .2382 554 
Bugnion et al. (2012); ACM Transactions on Computer Systems 

■ Performance Evaluation of Intel EPT Hardware Assist 

http : // www . vmware .com/ pdf /Perf_ESX_Intel-EPT-eval .pdf 
VMWare Inc. (2006-2009) 

■ Performance Aspects ofx86 Virtualization 

http : / /communities . vmware . com/ servlet/JiveServlet /download/ 1147 092- 17 9 54/ 
PS_TA68_288534_166-l_FIN_v5 .pdf 
Ole Agesen (2007); VMWare 
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■ Xen and the Art of Virtualization 

http : / / www . cl . cam. ac . uk/ net os /papers/ 2 003-xensosp .pdf 
Paul Barham, Boris Dragovic et al. (2003) 

■ KVM: The Linux Virtual Machine Monitor 

http: //kernel .org/doc/ols/2007/ols2 007vl-pages-225-230 .pdf 
Avi Kivity, Yaniv Kamay, Dor Laor, Uri Lublin, Anthony Liguori (2007) 
Qumranet / IBM) 

. KVM PV devices 

http : //www . linux-kvm. org/wiki/ image s/d/ dd/KvmForum2 007$kvm_pv. 
drv . pdf 

Dor Laor (2007); Qumranet 

■ How to break out of a chrootO jail 

http : / / www . bpf h . net/ computing/ docs/ chroot -break . html 

Simes (2002) 

■ Notes from a container 

http: //Iwn . net /Articles/25 638 9/ 

Jonathan Corbet (2007); Linux Weekly News 
. CGROUPS 

https : / /www . kernel . org/ doc /Document at ion/ cgroups/ cgroups . txt 
Paul Menage (Google) (2004-2006), kemel.org 
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El medio f isico y el 
almacenamiento 

C.l. El medio fisico 

A lo largo del presente texto, particularmente de los capltulos 6 y 7 y si- 
guiendo las practicas a que ha impuesto la realidad de los liltimos 40 anos, 
el termino generico de disco se ha empleado practicamente como sinonimo de 
medio de almacenamiento a largo plazo. 

En este apendice se abordan en primer termino las caracteristicas princi- 
pales del medio aiin prevalente, los discos duros magneticos rotativos, y una 
introduccion a las diferencias que presentan respecto a otros medios, como los 
discos opticos y los de estado solido, as! como las implicaciones que estos tie- 
nen sobre el material presentado en el capitulo 7. 

Cabe mencionar que la razon de separar este contenido hacia un apendice 
es que, si bien estas funciones resultan relevantes para los sistemas operativos y 
estos cada vez mas van asumiendo las funciones que aqul seran descritas, estas 
comenzaron siendo implementadas por hardware especializado; fue apenas 
hasta la aparicion de los esquemas de manejo avanzado de voliimenes (que 
seran cubiertos en la seccion C.3) que entran al ambito del sistema operativo. 

C.1.1. Discos magneticos rotativos 

El principal medio de almacenamiento empleado en los liltimos 40 anos es 

el disco magnetico. Hay dos tipos diferentes de disco, aunque la logica de su 
ftincionamiento es la misma: los discos duros y los flexibles {o floppies). 

La principal diferencia entre estos es que, los primeros, son tipicamente al- 
macenamiento interne en los equipos de computo y, los segundos, fueron pen- 
sados para ser almacenamiento transportable. Los discos duros tienen mucha 
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mayor capacidad y son mucho mas rapidos, pero a cambio de ello, son corres- 
pondientemente mas sensibles a la contaminacion por particulas de polvo y a 
danos mecanicos, razon por la cual hoy en dia se venden, ]\mto con el mecanis- 
mo lector e incluso la electronica de control, en empaque sellado. 

Un disco flexible es una hoja de material plastico, muy similar al empleado 
en las cintas magneticas, resguardado por un estuche de plastico. Al insertarse 
el disco en la unidad lectora, esta lo hace girar sujetandolo por el centro, y 
las cabezas lectoras (en un principio una sola; posteriormente aparecieron las 
unidades de doble cara, con dos cabezas lectoras) se deslizan por una ventana 
que tiene el estuche. 

La mayor parte de los discos flexibles presentaban velocidades de rotacion 
de entre 300 y 400 revoluciones por minuto — presentaban, pues, una demora 
rotacional de entre 0.15 y 0.2 segimdos. La demora rotacional es el tiempo que to- 
ma la cabeza lectora en volver a posicionarse sobre un mismo sector del disco. 
(Vease la figura C.l) 

A lo largo de mas de 20 anos se presentaron muy diferentes formatos fisicos 
siguiendo esta misma logica, designandose principahnente por su tamano (en 
pulgadas). La capacidad de los discos, claro esta, fue creciendo con el paso de 
los anos — esto explica la aparente contradiccion de que los discos (fisicamente) 
mas chicos tenian mas capacidad que los mas grandes. 

Cuadro C.l: Principales formatos de disco flexible que se popularizaron en el mer- 
cado. 





8 pulgadas 


5.25 pulgadas 


3.5 pulgadas 


Fecha de introduccion 


1971 


1976 


1982 


Capacidad 


150 KB a 1.2 MB 


110 KB a 1.2 MB 


264 KB a 2.88 MB 


Velocidad (kbit/s) 


33 


125-500 


250-1000 


Pistas por pulgada 


48 


48-96 


135 



El nombre de disco duro o disco flexible se debe al medio empleado para el al- 
macenamiento de la informacion (y no a la rigidez de su estuche, como mucha 
gente erroneamente cree): mientras que los discos flexibles emplean una ho- 
ja plastica flexible, los duros son metalicos. Los discos estan permanentemente 
montados sobre un eje, lo que permite que tengan una velocidad de giro entre 
20 y 50 veces mayor que los discos flexibles — entre 4 200 y 15 000 revolucio- 
nes por minuto (rpm), esto es, con una demora rotacional de entre dos y 7.14 
milisegundos. 

Ademas, a excepcion de algimos modelos tempranos, los discos duros cons- 
tituyen un paquete cerrado y sellado que incluye las cabezas de lectura y escri- 
tura, y toda la electronica de control. Esto permite que los discos duros tengan 
densidades de almacenamiento y velocidades de transmision muy superiores 
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a la de los discos flexibles: los primeros discos duros que se comercializaron 
para computadoras personales eran de 10 MB (aproximadamente 70 discos fle- 
xibles de su epoca), y actualmente hay ya discos de 4 TB. La velocidad maxima 
de transferencia sostenida hoy en dla es superior a los 100 MB por segundo, 100 
veces mas rapido que la ultima generacion de discos flexibles. 

Para medir la eficiencia de un disco duro, ademas de la demora rotacional 
presentada unos parrafos atras, el otro dato importante es el tiempo que toma 
la cabeza en mo verse por la superficie del disco. Hoy en dla, las velocidades 
mas comunes son de 20 ms para un recorrido completo (desde el primer hasta el 
ultimo sector), y entre 0.2 y 0.8 ms para ir de un cilindro al inmediato siguiente. 
Como punto de comparacion, el recorrido completo en una unidad de disco 
flexible toma aproximadamente 100 ms, y el tiempo de un cilindro al siguiente 
va entre 3 y 8 ms. 

Notacion C-H-S 

En un pruicipio, y hasta la decada de los noventa, el sistema opera tivo siem- 
pre hacla referenda a la ubicacion de un bloque de informacion en el disco em- 
pleando la notacion C-H-S — indicando el cilindro, cabeza y sector {Cylinder, 
Head, Sector) para ubicar a cada bloque de datos. Esto permite mapear el es- 
pacio de almacenamiento de un disco a un espacio tridimensional, con el cual 
resulta trivial ubicar un conjunto de datos en una region contigua. 




Figura C.l: Coordenadas de un disco duro, ilustrando su geometria basada en ca- 
beza, cilindro y sector (imagen de la Wikipedia: Cilindro Cabeza Sector). 

La cabeza uidica a cual de las superficies del disco se hace referenda; en 
im disco flexible hay solo una o dos cabezas (cuando aparecieron las unidades 
de doble lado eran un lujo y, al paso de los anos, se fueron convirtiendo en la 
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norma), pero en un disco duro es comiin tener varios platos paralelos. Todas las 
cabezas van fijas a un mismo motor, por lo que no pueden moverse de forma 
independiente. 

El cilindro indica la distancia del centro a la orilla del disco. Al cilindro tam- 
bien se le conoce como pista (track), ima metafora heredada de la epoca en que 
la miisica se distribuia principalmente en discos de vinil, y se podia ver a sim- 
ple vista la frontera entre una pista y la siguiente. 

Un sector es un segmento de arco de uno de los cilindros y contiene siempre 
la misma cantidad de informacion (historicamente 512 bytes; actualmente se 
estan adoptando gradualmente sectores de 4 096 bytes. Refierase a la seccion 
C.1.1 para una mayor discusion al respecto.) 

Un archivo aLmacenado secuenciaLmente ocupa sectores adyacentes a lo largo 
de tma misma pista y con una misma cabeza. 

Algoritmos de planiiicacion de acceso a disco 

Las transferencias desde y hacia los discos son uno de los procesos mas 
lentos de los que gestiona el sistema operativo. Cuando este tiene varias soli- 
citudes de transferencia pendientes, resulta importante encontrar un mecanis- 
mo Optimo para realizar la transferencia, minimizando el tiempo de demora. A 
continuacion se describiran a grandes rasgos tres de los algoritmos historicos 
de planificacion de acceso a disco — para abordar despues el por que estos hoy 
en dla casi no son empleados. 

Como con los demas escenarios en que se han abordado algoritmos, para 
analizar su rendimiento, el analisis se realizara sobre \ma cadena de referenda. 
Este ejemplo supone un disco hipotetico de 200 cilindros, la cadena de solicitu- 
des 83, 175, 40, 120, 15, 121, 41, 42, y teniendo la cabeza al inicio de la operacion 
en el cilindro 60. 

En la figuja C.2 puede apreciarse de forma grafica la respuesta que presen- 
tarlan los distintos algoritmos ante la cadena de referencia dada. 

FIFO Del mismo modo que cuando fueron presentados los algoritmos de asig- 
nadon de procesador y de reemplazo de paginas, el primero y mas sen- 
cillo de implementar es el FIFO — primero llegado, primero servido. 

Este algoritmo puede verse como muy justo, aunque sea muy poco efi- 
ciente: el movimiento total de cabezas para el caso planteado es de 622 
cilindros, equivalente a poco mas que recorrer de extremo a extremo el 
disco complete tres veces. Esto es, despreciando la demora rotacional la 
demora mecanica para que el brazo se detenga por completo antes de 
volver a moverse, esta lectura tomaria wx minimo de 60 ms, siendo el 
recorrido completo del disco 20 ms. 

Puede identificarse como causante de buena parte de esta demora a la 
quinta posicion de la cadena de referencia: entre solicitudes para los ci- 
lindros contiguos 120 y 121, llego una solicitud al 15. 
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Operaciones 



Figura C.2: Movimientos de las cabezas bajo los diferentes algoritmos planifica- 
dores de acceso a disco, indicando la distancia total recorrida por la cabeza bajo 
cada uno, iniciando con la cabeza en la posicion 60. Para SCAN, LOOK y C-SCAN, 
se asume que la cabeza inicia avanzando en direccion decreciente. 



Atender esta solicitud en FIFO significa un desplazamiento de (120 — 
15) + (121 — 15) = 211 cilindros, para volver a quedar practicamente 
en el mismo lugar de inicio. Una sola solicitud resulta responsable de la 
tercera parte del tiempo total. 

SSTF Ahora bien, si el factor que impone la principal demora es el movimiento 
de la cabeza, el segundo algoritmo busca reducir al mmimo el movimien- 
to de la cabeza: SSTF {Shortest Seek Time First, Tiempo de busqueda mas corto 
a continuacion) es el equivalente en este ambito del Proceso mas corto a 
continuacion, presentado en la seccion 4.2.4 — con la ventaja de no estar 
prediciendo comportamiento futuro, sino partir de una lista de solicitu- 
des pendientes. Empleando SSTF, el tiempo de desplazamiento para este 
caso se reduce a tan solo 207 cilindros, muy cerca del mrnimo absoluto 
posible. 

Una desventaja de SSTF es que puede llevar a la rnanicion: si hay una 
gran densidad de solicitudes para cilindros en determinada zona del dis- 
co, una solicitud para un cilindro alejado puede quedar a la espera inde- 
finidamente. 

Ejemplificando esto con una serie de solicitudes distinta a la cadena refe- 
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rencia: si el sistema tuviera que atender solicitudes por los cilindros 15, 
175, 13, 20, 14, 32, 40, 5, 6, 7, SSTF penaUzaria a la segunda solicitud (175) 
hasta terminar con los cilindros bajos. Si durante el tiempo que tome res- 
ponder a estas solicitudes llegan otras adicionales, el proceso que esta 
esperando el contenido del cilindro 175 puede quedar en espera indefini- 
da. 

Familia de algoritmos de elevador (SCAN, LOOK, C-SCAN) En este tercer lu- 
gar se abordara ya no un solo algoritmo, sino que una familia, dado que 
parten de la misma idea, pero con modificaciones menores Uevan a que 
el patron de atencion resultante sea muy distinto. 

El planteamiento base para el algoritmo basico de elevador (SCAN) bus- 
ca evitar la inanicion, minimizando al mismo tiempo el movimiento de 
las cabezas. Su logica indica que la cabeza debe recorrer el disco de un 
extremo a otro, como si fuera un elevador en un edificio alto, atendien- 
do a todas las solicitudes que haya pendientes en su camino. Si bien los 
recorridos para ciertos patrones pueden resultar en mayores desplaza- 
mientos a los que daria SSTF, la garantia de que ningun proceso esperara 
indefinidamente lo hace muy atractivo. 

Atender la cadena de referenda bajo SCAN, asumiendo un estado inicial 
descendente (esto es, la cabeza esta en el cilindro 60 y va bajando) da un re- 
corrido total de 235 cilindros; empleando LOOK, se reduce a 205 cilindros, 
y evita el movimiento innecesario hasta el lunite del disco. 

Una primer (y casi obvia) modificacion a este algoritmo seria, cada vez 
que la cabeza se detenga para satisfacer una solicitud, verificar si hay 
alguna otra solicitud pendiente en la direccion actual, y de no ser asi, em- 
prender el camino de regreso sin Uegar a la orilla del disco. Esta modifi- 
cacion es frecuentemente descrita como LOOK. 

Sin embargo, el patron de atencion a solicitudes de SCAN y look de- 
jan que desear: al llegar a un extremo del recorrido, es bastante probable 
que no haya ninguna solicitud pendiente en la primer mitad del recorri- 
do de vuelta (dado que acaban de ser atendidas). El tiempo que demora 
atender a \ma solictud se compone de la suma del desplazamiento de la 
cabeza y la demora rotacional (que depende de cual sector del cilindro 
fue solicitado). Para mantener una tasa de transferencia mas predecible, 
el algoritmo C-SCAN (SCAN Circular) realiza las operaciones en el disco 
unicamente en un sentido — si el algoritmo lee en orden descendente, al 
llegar a la solicitud del cilindro mas bajo, saltara de vuelta hasta el mas 
alto para volver a iniciar desde ahi. Esto tiene como resultado, claro, que 
el recorrido total aumente (airaientando hasta los 339 para la cadena de 
referenda presentada). 
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Limitaciones de los algoritmos presentados 

Ahora bien, ipor que se menciono que estos algoritmos hoy en dla ya casi 
no se usan? 

Hay varias razones. En primer termino, todos estos algoritmos estan orien- 
tados a reducir el traslado de la cabeza, pero ignoran la demora rotacional. Como 
se explico, en los discos duros actuales, la demora rotacional va entre y j del 
tiempo total de recorrido de la cabeza. Y si bien el sistema podrla considerar 
esta demora como un factor adidonal al planificar el siguiente movimiento de 
forma que se redujera el tiempo de espera, los algoritmos descritos obviamente 
requieren ser replanteados por completo. 

For otro lado, el sistema operativo muchas veces requiere dar distintas prio- 
ridades a los diferentes tipos de solicitud. Por ejemplo, se esperaria que diera 
preferencia a los accesos a memoria virtual por encima de las solicitudes de 
abrir un nuevo archivo. Estos algoritmos tampoco permiten expresar esta ne- 
cesidad. 

Pero el tercer punto es mucho mas importante aiin: del mismo modo que 
los procesadores se van haciendo mas rapidos y que la memoria es cada vez 
de mayor capacidad, los controladores de discos tambien son cada vez mas 
inteligentes, y esconden cada vez mas informacion del sistema operativo, por lo 
cual este cada vez mas carece de la informacion necesaria acerca del acomodo 
real de la informacion como para planificar correctamente sus accesos. 

Uno de los cambios mas importantes en este sentido fue la transicion del 
empleo de la notacion C-H-S al esquema de direccionamiento logico de bloques 
{Logical Block Addressing, LBA) a principios de los noventa. Hasta ese momen- 
to, el sistema operativo tenia informacion de la ubicacion /fsfcfl de todos los 
bloques en el disco. 

Una de las desventajas, sin embargo, de este esquema es que hacia necesario 
que el BIOS conociera la geometrta de los discos — y este presentaba limites 
duros en este sentido: principalmente, no le era posible referenciar mas alia 
de 64 cilindros. Al aparecer la interfaz de discos IDE (electrdnica integrada al 
dispositivo) e ir reemplazando a la ST-506, se introdujo LBA. 

Este mecanismo convierte la direccion C-H-S a una direccion lineal, presen- 
tando el disco al sistema operativo ya no como un espacio tridimensional, sino 
que como un gran arreglo de bloques. En este primer momento, partiendo de 
que CPC denota el numero de cabezas por cilindro y SPC el numero de sectores 
por cilindro, la equivalencia de una direccion C-H-S a una lba era: 

LBA = {{Cilindro x CPC) -|- Cabeza) x SPC + Sector - 1 

La transicion de CHS a lba significo mucho mas que una nueva notacion: 
marco el inicio de la transferencia de inteligencia y control del CPU al controla- 
dor de disco. El efecto de esto se refleja directamente en dos factores: 
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Sectores variables por cilindro En casi todos los discos previos a LBA,^ el nii- 
mero de sectores por pista se mantenla constante, se tratara de las pistas 
mas internas o mas externas. Esto significa que, a igual calidad de la co- 
bertura magnetica del medio, los sectores ubicados en la parte exterior 
del disco desperdiciaban mucho espacio (ya que el area por bit era mucho 
mayor). 




Figura C.3: Disco formateado bajo densidad de hits por zona, con mas sectores por 
pista en las pistas exteriores (imagen de la Wikipedia: Zone Bit Recording). 

Bajo LBA, los discos duros comenzaron a emplear un esquema de densidad 
de hits por zona {zone hit recording), con la que en los cilindros mas externos 
se aumenta. 

Reubicacion de sectores Conforme avanza el uso de un disco, es posible que 
algunos sectores vayan resultando dif idles de leer por danos microscopi- 
cos a la superficie. El controlador es capaz de detectar estos problemas, y 
de hecho, casi siempre puede rescatar la informacion de dichos sectores 
de forma imperceptible al usuario. 

Los discos duros ST-506 tlpicamente iban acompafiados por una lista de 
defectos, una lista de coordenadas C-H-S que desde su fabricacion hablan 
presentado errores. El usuario debia ingresar estos defectos al formatear 
el disco a hajo nivel. 

Hoy en dla, el controlador del disco detecta estos f alios y se los salta, pre- 
sentando un mapa LBA lineal y completo. Los discos duros tlpicamen- 
te vienen con cierto niimero de sectores de reserva para que, conforme se 

^Las unidades de disco Commodore 1541 y Macintosh Superdrive, que empleaban velocidad varia- 
ble por cilindro para aprovechar mejor el medio magnetico, constituyen notorias excepciones; en 
ambos casos, sin embargo, terminaron desapareciendo por cuestiones de costos y de complejidad 
al sistema. 
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van detectando potenciales danos, estos puedan reemplazarse de forma 
transparente. 

A estos factores se suma que a los controladores de disco se les agrego tam- 
bien una memoria cache dedicada para las operaciones de lectura y escritura. 
El controlador del disco es hoy en dia capaz de implementar estos mismos al- 
goritmos de forma completamente autonoma del sistema operativo. 

Y si bien las diferentes ujiidades de disco duro habian mantenido sectores 
de 512 bytes desde los primeros discos duros, a partir de la aprobacion del 
Formato Avanzado en 2010 que incrementa los sectores a 4 096 bytes, presenta 
otra abstraccion mas: un disco con sectores de 4 096 bytes que es empleado por 
el sistema operativo como si fuera de 512-^ tiene que efectuar, dentro de la logica 
de su controlador, una emulacion — y una modificacion de \m solo sector se 
vuelve un ciclo lectura-modificacion-escritura (RMW), que redunda en una espera 
de por lo menos una revolucion adicional (8 ms con un disco de 7 200 RPM) del 
disco antes de que la operacion pueda completarse. 

Resulta claro que, dados estos cambios en la manera en que debe referirse 
a los bloques del disco, el sistema operativo no cuenta ya con la informacion 
necesaria para emplear los algoritmos de planificadon de acceso a disco. 

C.1.2. Almacenamiento en estado solido 

Desde hace cerca de una decada va creciendo consistentemente el uso de 
medios de almacenamiento de estado solido — esto es, medios sin partes movi- 
les. Las caracteristicas de estos medios de almacenamiento son muy distintas 
de las de los discos. 

Si bien las estructuras logicas que emplean hoy en dia practicamente todos 
los sistemas de archivos en uso mayoritario estan pensadas siguiendo la logica 
de los medios magneticos rotativos, como se vera en esta seccion, el empleo de 
estructuras mas acordes a las caracteristicas del medio fisico. Este es induda- 
blemente un area bajo intensa investigacion y desarroUo, y que seguxamente 
ofrecera unportantes novedades en los proxunos anos. 

Lo primero que llama la atencion de estos medios de almacenamiento es 
que, a pesar de ser fundamentalmente distintos a los discos magneticos, se pre- 
sentan ante el sistema operativo como si fueran lo mismo: en lo que podria en- 
tenderse como un esfuerzo para ser utilizados pronto y sin tener que esperar a 
que los desarrolladores de sistemas operativos adecuaran los controladores, se 
conectan mediante la misma interfaz y empleando la misma semantica que un 
disco rotativo.^ Esto no solo evita que se aprovechen sus caracteristicas unicas, 

^ Al dia de hoy, los principales sistemas operativos pueden ya hacer referencia al nuevo tamafio 
de bloque, pero la cantidad de equipos que ejecutan sistemas heredados o de controladores que no 
permiten este nuevo modo de acceso Umitan una adopcion al 100 por ciento. 

^Las imidades de estado s61ido cuentan con ima capa de traduccion que emula el comportamiento 
de un disco duro, y presenta la misma interfaz tanto de bus como semintica. 
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adoptando restricciones y criterios de diseno que ahora resultan indudable- 
mente artificiales, sino que incluso se exponen a mayor stress por no emplearse 
de la forma que les resultaria natural. 

Antes de ver por que, conviene hacer un breve repaso de los tipos de discos 
de estado solido que hay. Al hablar de la tecnologia sobre la cual se implementa 
este tipo de almacenamiento, los principales medios son: 

NVRAM Unidades RAM No Volatil. Almacenan la informacion en chips de 
RAM estandar, con un respaldo de baterla para mantener la informacion 
cuando se desconecta la corriente externa. Las primeras unidades de esta- 
do solido eran de este estilo; hoy en dia son poco comunes en el mercado, 
pero todavla hay. 

Su principal ventaja es la velocidad y durabilidad: el tiempo de acceso o 
escritura de datos es el mismo que el que podria esperarse de la memoria 
principal del sistema, y al no haber demoras mecanicas, este tiempo es el 
mismo independientemente de la direccion que se solicite. 

Su principal desventaja es el precio: en Imeas generales, la memoria RAM 
es, por volumen de almacenamiento, cientos de veces mas cara que el 
medio magnetico. Y si bien el medio no se degrada con el uso, la baterla 
SI, lo que podria poner en peligro a la supervivencia de la informacion. 

Estas unidades tlpicamente se instalan intemamente como una tarjeta de 
expansion. 




Figura C.4: Unidad de estado solido basado en RAM: DDRdrive XI (imagen de la 
Wikipedia: Solid state drive). 

Memoria flash Derivada de los EEPROM {Electrically Erasable Programmable 
Read-Only Memory, Memoria de Solo Lectura Programable y Borrable Electri- 
camente). Los EEPROM tienen la caracterlstica de que, ademas de lectura y 
escritura, hay un tercer tipo de operacion que deben implementar: el bo- 
rrado. Un EEPROM ya utilizado debe borrarse antes de volverse a escribir 
a el. La principal caracterlstica que distingue a las memorias/Zas/i de los 
EEPROM tradicionales es que el espacio de almacenamiento esta dividido 
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en muchas celdas, y el controlador puede leer, borrar o escribir a cada uno 
de ellos por separado.* 

El uso de dispositivos flash para almacenamiento de informacion inicio 
hacia 1995 como respuesta a las necesidades de las industrias aeroespa- 
cial y militar, dada la frecuencia de los dafios a la informacion que pre- 
sentaban los medios magneticos por la vibracion. Hoy en dla hay dispo- 
sitivos /Zfls/z de muy bajo costo y capacidad, aunque presentan una gran 
variabilidad tanto en su tiempo de acceso como en su durabilidad. En 
este sentido, hay dos tipos principales de dispositivos /Zas/z: 

Almacenamiento primario (SSD) Las llamadas formalmente unidad de 
estado solido {Solid State Drive)^ son unidades Flash de alta veloci- 
dad y capacidad, y tlpicamente presentan una rnterfaz similar a la 
que tienen los discos duros; hoy en dla, la mas comun es SATA. 




Figura C.5: Unidad de estado solido basado en Flash con interfaz SATA (imagen de 
la Wikipedia: Solid state drive). 

Su velocidad de lectura es muy superior y su velocidad de escritura 
(incluyendo el borrado) es comparable a la de los discos magneticos. 
Su precio por el mismo volumen de almacenamento es entre 5 y 10 
veces el de los discos magneticos. 

Estas imidades se emplean tanto como unidades independientes en 
servidores, equipos de alto desempeno e incluso algunas subporta- 
tiles (netbooks) o como un componente de la tarjeta madre en dispo- 
sitivos moviles como telefonos y tabletas. 

Transporte de archives Esta tecnologia tambien esta presente en las di- 
versas unidades extraibles o moviles, como las unidades USB, SD, 

^Estos dispositivos se conocen como flash en referencia a los chips EPROM (antes de que fuera 
posible borrar electricamente): estos chips tenfan una ventana en la parte superior, y debian operar 
siempre cubiertos con una etiqueta. Para borrar sus contenidos, se retiraba la etiqueta y se les 
administraba una descarga luminica — un flash. 

^Un error muy comiin es confundir la D con Disk, que denotaria que Uevan un disco, un medio 
rotativo. 
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Memory Stick, Compact Flash, etc. La principal diferencia entre es- 
tas son los diferentes conectores que emplean; todas estas tecnolo- 
gias presentan dispositivos que varian fuertemente en capacidad, 
velocidad y durabilidad. 




Figura C.6: Unidad de estado solido basado en Flash con interfaz USB (imagen de 
la Wikipedia: Solid state drive). 

Independientemente del tipo, las unidades de estado solido presentan ven- 
tajas ante los discos rotativos, como un muy bajo consumo electrico, operacion 
completamente silenciosa, y resistencia a la vibracion o a los golpes. Ademas, el 
medio es verdaderamente de acceso aleatorio: al no ser ya un disco, desaparecen 
tanto la demora de movuniento de cabezas como la rotacional. 

Desgaste del medio 

La memoria Flash presenta patrones de desgaste muy distintos de los que 
presentan otros medios. La memoria Flash tiene capacidad de aguantar un cier- 
to niimero de operaciones de borrado por pagina^ antes de comenzar a degra- 
darse y fallar. Las estructuras tradicionales de sistemas de archives basados en 
disco concentran una gran cantidad de modificaciones frecuentes a lo largo de la 
operacion normal del sistema en ciertas regiones clave: las tablas de asignacion 
y directories registran muchos mas cambios que la region de datos. 

Casi todos los controladores de discos Flash cuentan con mecanismos de 
nivelamiento de escrituras {write leveling). Este mecanismo busca reducir el des- 
gaste focalizado modificando el mapeo de los sectores que ve el sistema opera- 
tive respecto a los que son grabados en verdad en el medio: en vez de actualizar 
im bloque (por ejemplo, un directorio) en su lugar, el controlador le asigna un 
nuevo bloque de forma transparente, y marca el bloque original como libre. 

Los mecanismos mas simples de nivelamiento de escrituras lo hacen unica- 
mente intercambiando los bloques libres con los recien reescritos; mecanismos 
mas avanzados buscan equilibrar el nivel de reescritura en toda la unidad re- 
ubicando periodicamente tambien a los bloques que no son modificados, para 
no favorecerlos rnjustamente y hacer un mejor balanceo de uso. 

^Dependiendo de la calidad, va entre las 3 000 y 100 000. 
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Emulacion de discos 

Hoy en dia, casi la totalidad de medios de estado solido se presentan ante 
el sistema con una interfaz que emula la de los discos, la FTL {Flash Translation 
Layer, Capa de Traduccion de Flash). La ventaja de esta emulacion es que no hi- 
zo falta desarroUar controladores adicionales para comenzar a emplear estos 
medios. La desventaja, sin embargo, es que al ocultarse el funcionamiento real 
de las unidades de estado solido, el sistema operativo no puede aprovechar las 
ventajas estructurales — y mas importante aiin, no puede evitar las debilidades 
inherentes al medio. 

Uno de los ejemplos mas claros de esta falta de control real del medio la 
ilustra el artlculo de Valerie Aurora (2009), que menciona que tanto la poca in- 
formacion piiblicamente disponible acerca del funcionamiento de los controla- 
dores como los patrones de velocidad y desgaste de los mismos apuntan a que 
la estructura subyacente de casi todos los medios de estado solido es la de un 
sistema de archives estructurado en bitdcora. Aurora indica que hay varias opera- 
ciones que no pueden ser traducidas eficientemente por medio de esta capa de 
emulacion, y que seguramente permitirfan vn mucho mejor aprovechamiento 
del medio. Como se menciono en la seccion 7.3.5 (Sistemas de archive estructu- 
rados en bitdcora), si bien varios de estos sistemas de archivos han presentado 
implementaciones completamente utilizables, la falta de interes ha llevado a 
que muchos de estos proyectos sean abandonados. 

En su artlculo de 2012, Neil Brown apunta a que Linux tiene una interfaz 
apta para hablar directamente con dispositivos de estado solido, llamada mtd 
— memory technology devices, dispositivos de tecnologia de memoria. 

Si bien los discos duros se han empleado por ya 50 anos y los sistemas de 
archivos estan claramente desarrollados para aprovechar sus defalks fisicos y 
logicos, el uso de los dispositivos de estado solido apenas esta despegando en 
la ultima decada. Y si bien esta primer aproximacion que permite emplear esta 
tecnologia transparentemente es suficientemente buena para muchos de los usos 
basicos, sin duda hay espacio para mejorar. Este es un tema que seguramente 
brinda amplio espacio para investigacion y desarroUo para los proximos afios. 



C.2. RAID: Mas alia de los limites fisicos 

En la seccion 7.1.1 se presento muy escuetamente al concepto de volumen, 
mencionando que vn volumen ttpicamente coincide con una particion, aunque 
no siempre es el caso — sin profundizar mas al respecto. En esta seccion se 
presentara uno de los mecanismos que permite combinar diferentes dispositivos 
fisicos en un solo volumen, Uevando -bajo sus diferentes modalidades- a mayor 
confiabilidad, rendimiento y espacio disponible. 

El esquema mas difundido para este fin es conocido como RAID, Arreglo Re- 
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dundante de Discos Baratos {Redundant Array of Inexpensive Disks)/ propuesto en 
1988 por David Patterson, Garth Gibson y Randy Katz ante el diferencial que 
se presentaba (y se sigue presentando) entre el avance en velocidad y confia- 
bilidad de las diversas areas del computo en relacion con el ahnacenamiento 
magnetico. 

Bajo los esquemas raid queda sobreentendido que los diferentes discos que 
forman parte de un volumen son del mismo tamano. Si se reemplaza un disco 
de un arreglo por uno mas grande, la capacidad en exceso que tenga este sobre 
los demas discos sera desperdiciada. 

Por muchos anos, para emplear un arreglo RAID era necesario contar con 
controladores dedicados, que presentaban al conjunto como un dispositivo 
linico al sistema operativo. Hoy en dia, practicamente todos los sistemas opera- 
tivos incluyen la capacidad de integrar varias unidades independientes en vin 
arreglo por software; esto conlleva un impacto en rendimiento, aunque muy 
pequeno. Hay tambien varias tecnologfas presentes en distintos sistemas ope- 
rativos modemos que heredan las ideas presentadas por RAID, pero integran- 
dolos con funciones formalmente implementadas por capas superiores. 

La operacion de raid, mas que un unico esquema, especifica un conjunto 
de niveles, cada uno de ellos disenado para mejorar distintos aspectos del al- 
macenamiento en discos. Se exponen a continuacion las caracteristicas de los 
principales niveles en uso hoy en dia. 

C.2.1. RAID nivel 0: division enfranjas 

El primer nivel de RAID brinda una ganancia tanto en espacio total, dado 
que presenta tm volumen grande en vez de varios discos mas pequenos (sim- 
plificando la tarea del administrador) como de velocidad, dado que las lecturas 
y escrituras al volumen ya no estaran sujetas al movimiento de una sola cabe- 
za, sino que habra vma cabeza independiente por cada \mo de los discos que 
conformen al volumen. 
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Figura C.7: Cinco discos organizados en RAID 0. 

Los discos que participan en un volumen RAID 0 no estan sencUlamente 
concatenados, sino que los datos son divididos enfranjas (en ingles, el proceso se 
conoce como striping, de la palabra stripe, franja; algunas traducciones al espa- 
nol se refieren a este proceso como bandeado). Esto hace que la carga se reparta 

''Ocasionalmente se presenta a RAID como acrdnimo de Arreglo Redundante de Discos Indepen- 
dientes (Redundant Array of Independent Disks) 
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de forma uniforme entre todos los discos, y asegura que todas las transferencias 
mayores al tamano de una franja provengan de mas de un disco independiente. 
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Figura C.8: Divisi6n de datos enfranjas. 

La confiabilidad del volumen, sin embargo, disminuye respecto a si cada 
vno de los discos se manejara por separado: basta con que vno de los discos 
presente danos para que la informacion contenida en el volumen se pierda. 

Un arreglo RAID nivel 0 puede construirse con un mmimo de dos discos. 



C.2.2. RAID nivel 1: espejo 

Este nivel esta principalmente orientado a aumentar la confiabilidad de la 
informacion: los datos son grabados de forma simultdnea e identica en todos 
los discos que formen parte del volumen. El costo de mantener los datos en 
espejo, claro esta, es el del espacio empleado: en su configuracion habitual, 
de dos discos por volumen, 50% del espacio de almacenamiento se pierde por 
fimgir como respaldo del otro 50 por ciento. 

La velocidad de acceso a los datos bajo raid 1 es mayor a la que se logra- 
ria con un disco tradicional: basta con obtener los datos de uno de los discos; 
el controlador raid (sea el sistema operativo o una implementacion en hard- 
ware) puede incluso programar las solicitudes de lectura para que se vayan 
repartiendo entre ambas unidades. La velocidad de escritura se ve levemente 
reducida, dado que hay que esperar a que ambos discos escriban la informa- 
cion. 



Volumen (1TB) 




Figura C.9: Dos discos en espejo con RAID 1. 
Un arreglo RAID nivel 1 se construye tipicamente con dos discos. 
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C.2.3. Los niveles 2, 3 y 4 de RAID 

Los siguientes tres niveles de raid combinan propiedades de los primeros 
junto con un algoritmo de verificacion de integridad y correccion de errores. 
Estos han caido casi por completo en el desuso dado que los otros niveles, y 
muy en particular el nivel 5, ofrecen las mismas caracteristicas, pero con mayor 
confiabilidad 



C.2.4. RAID nivel 5: paridad dividida por bloques 

El nivel 5 de RAID proporciona un muy buen equilibrio respecto a las carac- 
teristicas que se han mencionando: brinda el espacio total de aLmacenamiento 
de todos los discos que formen parte del volumen menos uno. Para cada una de 
las franjas, RAID 5 calcula un bloque de paridad. 

Para obtener ima mayor tolerancia a fallos, este bloque de paridad no siem- 
pre va al mismo disco, sino que se va repartiendo entre todos los discos del 
volumen, desplazdndose a cada franja, de modo que cualquiera de los discos puede 
fallar, y el arreglo continuara operando sin perdida de informacion. Esta debe 
notificarse al administrador del sistema, quien reemplazara al disco danado lo 
antes posible (dado que, de no hacerlo, la falla en un segundo disco resultara 
en la perdida de toda la informacion). 

En equipos RAID profesionales es comun contar con discos de reserva en 
caliente {hot spares): discos que se mantienen apagados pero listos para trabajar. 
Si el controlador detecta un disco danado, sin esperar a la intervencion del 
administrador, desactiva al disco afectado y activa al hot spare, reconstruyendo 
de inmediato la informacion a partir de los datos en los discos sanos. 
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Figura C.IO: Divisi6n de datos en franjas, con paridad, para RAID 5. 



Dependiendo de la configuracion, la velocidad de acceso de este nivel pue- 
de ser es ligeramente menor que la obtenida de los discos que no operan en 
RAID, o ligeramente menor a la que se logra con raid nivel 0. Dado que la elec- 
tronica en los discos actuales notificara explicitamente al sistema operativo en 
caso de fallo de lectura, cuando el sistema requiere leer datos, estos pueden ser 
solicitados linicamente a n — 1 discos (e ignorar al de paridad); si el arreglo esta 
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configurado para verificar la paridad en lecturas, todas tendran que obtener la 
franja correspondiente de todos los discos del arreglo para poder calcularla. 

El algoritmo de verificacion y recuperacion de RAID 5 es sorprendentemen- 
te eficiente y simple: el de una suma XOR, ilustrado en la figura C.ll. La opera- 
cion booleana XOR (de Exclusive OR) suma los bits individuales, columna por 
columna. Si es un numero par, almacena un 0, si es impar, almacena un 1. Esta 
operacion es muy eficiente computacionalmente. 
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Figura C.ll: Para cada franja, el disco de paridad guarda la suma XOR de los bits 
de las franjas correspondientes de los otros discos; no importa cual disco falle, sus 
datos pueden recuperarse haciendo un XOR de los datos de los demas. 

Las escrituras son invariablemente mas lentas respecto tanto ante la ausen- 
cia de raid como en niveles 0 y 1, dado que siempre tendra que recalcularse 
la paridad; en el caso de una escritura minima (menor a una franja) tendra que 
leerse la franja entera de todos los discos participantes en el arreglo, recalcular- 
se la paridad, y grabarse en el disco correspondiente. 

Cuando uno de los discos falla, el arreglo comienza a trabajar en el modo 
interim de recuperacion de datos {Interim data recovery mode, tambien conocido 
como modo degradado), en el que todas las lecturas involucran a todos los discos, 
ya que tienen que estar recalculando y rellenando la informacion que provendria 
del disco danado. 



Volumen (4TB) 




Figura C.ll: Cinco discos organizados en RAID 5. La franja de paridad se va alter- 
nando, repartiendose entre todos los discos. 

Para implementar RAID nivel 5 son necesarios por lo menos tres discos. 
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aunque es comun verlos mas anchos, pues de este modo se desperdicia menos 
espacio en paridad. Si bien teoricamente un arreglo nivel 5 puede ser arbi- 
trariamente ancho, en la practica es muy raro ver arreglos con mas de cinco 
discos: tener un arreglo mas ancho aumentarla la probabilidad de falla. Si un 
arreglo que esta ya operando en el modo uiteruio de recuperacion de datos se 
encuentra con una falla en cualquiera de sus discos, tendra que reportar un 
fallo irrecuperable. 



C.2.5. RAID nivel 6: paridad por redundancia P+Q 

Se trata nuevamente de un nivel de RAID muy poco utilizado. Se basa en 
el mismo principio que el de RAID 5 pero, empleando dos distintos algorit- 
mos para calcular la paridad, permite la perdida de hasta dos de los discos del 
arreglo. La complejidad computational es sensiblemente mayor a la de RAID 
5, no solo porque se trata de un segundo calculo de paridad, sino porque este 
calculo debe hacerse empleando un algoritmo distinto y mas robusto — si bien 
para obtener la paridad P basta con hacer una operacion XOR sobre todos los 
segmentos de una franja, la segunda paridad Q tipicamente emplea al algorit- 
mo Reed-Solomon, paridad diagonal o paridad dual ortogonal. Esto conlleva a una 
mayor carga al sistema, en caso de que sea RAID por software, o a que el con- 
trolador sea de mayor costo por implementar mayor complejidad, en caso de 
ser hardware dedicado. 



Figura C.13: Cinco discos organizados en RAID 6. Al igual que bajo RAID 5, las 
franjas de paridad se van alternando entre todos los discos. 

El nivel 6 de RAID puede implementarse con cuatro o mas unidades, y si 
bien el espacio dedicado a la redundancia se incrementa a dos discos, la re- 
dundancia adicional que ofrece este esquema permite crear voWmenes con un 
mayor niimero de discos. 



Volumen (3TB) 
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C.2.6. Niveles combinados de RAID 

Viendo desde el punto de vista de la abstraccion presentada, RAID toma una 
serie de dispositivos de bloques y los combina en otro dispositive de bloques. 
Esto significa que puede tomarse una serie de volumenes RAID y combinarlos 
en uno solo, aprovechando las caracteristicas de los diferentes niveles. 

Si bien pueden combinarse arreglos de todo tipo, hay combinaciones mas 
frecuentes que otras. Con mucho, la mas popular es la de los niveles 1 + 0 — 
esta combinacion, frecuentemente llamada sencillamente RAID 10, ofrece un 
maximo de redundancia y rendimiento, sin sacrificar demasiado espacio. 



Volumen RAIDO 
resultante (3TB) 



Subvolumen 
RAIDl 3 (1TB) 




Figura C.14: Seis discos organizados en RAID 1+0. 

Con RAID nivel 10 se crean volumenes que suman por franjas unidades en 
espejo (un volumen RAID 0 compuesto de varios volumenes RAID 1). En caso 
de fallar cualquiera de las unidades del arreglo, esta puede ser reemplazada 
facilmente, operacion que no significara un trabajo tan intensive para el arreglo 
entero (solo para su disco espejo). 

Bajo este esquema, en el peor de los casos, un volumen con n discos fisi- 
cos esta conformado por j volumenes nivel 1, y por tanto puede soportar la 
perdida de hasta § discos — siempre que estos no formen parte de un mismo 
volumen nivel 1 . 

Esta combinacion ilustra como el orden de los factores si altera el producto: 
si en vez de la concatenacion de varias unidades espejeadas (un volumen nivel 
0 compuesto de varios volumenes nivel 1) se armara el arreglo en orden inverso 
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(esto es, como el espejeo de varias unidades concatenadas por franjas), ante un 
primer analisis pareceria se obtienen los mismos beneficios — pero analizando 
lo que ocurre en caso de falla, resulta claro que el nivel de redimdancia resulta 
mucho menor. 



Volumen RAIDl 
resultante (3TB) 



Subvolumen RAIDO 
2 (3TB) 




Figura C.15: Seis discos organizados en RAID 0+1, ilustrando como una combina- 
cion erronea puede reducir la tolerancia maxima a fallos del arreglo. 

En este caso, el arreglo soportara tambien el fallo de hasta j de sus discos, 
pero linicamente si ocurren en el mismo volumen *mid* 1 del espejo. 

Dado que RAID opera meramente agregando dispositivos de bloques en un 
nuevo dispositivo del mismo tipo, no tiene conocimiento de la informacion 
subyacente. Por tanto, si se perdieran al mismo tiempo el disco 1 (del subvolu- 
men 1) y el disco 5 (del subvolumen 2), resultarla en perdida de datos.^ 



C.3. Manejo avanzado de volumenes 

Los esquemas RAID vienen, sin embargo, de finales de la decada de los 
ochenta, y si bien han cambiado el panorama del almacenamiento, en los mas 
de 20 anos desde su aparicion, han sido ya super ados. El enfasis en el estudio 
de RAID (y no tanto en los desarrollos posteriores) se justifica dada la limpie- 
za conceptual que presentan, y dado que esquemas posteriores incluso hacen 
referenda expllcita en su documentacion al nivel de RAID que estarian reempla- 
zando. 

A continuacion se presentan brevemente dos esquemas avanzados de ges- 
tion de volumenes, principalmente ilustrando la direccion en que parece ir 

*0 por lo menos, en una tarea de reconstruccion manual, dada que la informacion completa 
puede aiin ser encontrada. Sin embargo, ambos volumenes del arreglo RAID 1 estarian danados e 
incompletos. 
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avanzando la industria en este campo. Dado que no presentan nuevos con- 
ceptos sino que solo ilustran como se integran los que se han expuesto en las 
ultimas paginas, la exposicion se limitara a presentar ejemplos de aplicacion, 
sin entrar mas que a uxi nivel descriptivo de su funcionamiento. 

C.3.1. LVM: el Gestor de Volumenes Logicos 

Una evolucion natiiral de los conceptos de raid es el lvm2 (segunda gene- 
radon del Logical Volume Manager, o Gestor de Volumenes Logicos) de Linux. La 
logica de operacion de LVM esta basada en los siguientes conceptos: 

Volumen ffsico Cada ujno de los discos o imidades disponibles. 

Grupo de volumenes Conjunto de volumenes flsicos que seran administiados 
como una sola entidad. 

Volumen logico Espacio dentro del grupo de volumenes que se presenta como 

un dispositivo, y que puede alojar sistemas de archivos. 

El esquema es limpio y elegante: LVM es una interfaz que permite, como 
dos pasos independientes, agregar diferentes volumenes flsicos a un grupo de vo- 
lumenes, para posteriormente -y siguiendo las necesidades del administrador 
del sistema, ya independientes del tamano de las umidades fisicamente exis- 
tentes- crear las unidades logicas, donde se alojaran los sistemas de archivos 
propiamente. 

Este esquema permite naturalmente una funcionalidad comparable con la 
de un RAID 0: puede crearse un grupo de volumenes con todos los discos que 
disponibles, y dentro de este crear tm volumen logico linico. Dependiendo de 
la configuracion, este volumen logico puede crecer abarcando todos los discos 
en cuestion, sea como simple concatenacion o dividiendose en franjas. 

Permite tambien la creacion de unidades espejo, con una operacion a gran- 
des rasgos equivalente a la de raid 1. Incluso, dentro de un mismo grupo de 
volumenes, pueden haber tanto volumenes logicos espejeados como otios que 
no lo esten, a diferencia de la estricta rigidez de RAID. 

Para los niveles 4, 5 y 6 de raid, la correspondencia es mas directa aiin: al 
crear un volumen, se le puede solicitar a LVM al crear un volumen logico que 
cree un volumen con ese nivel de raid — obviamente, siempre que cuente con 
suficientes volumenes flsicos. 

El esquema de LVM no brinda, pues, funcionalidad estrictamente distinta 
a la que presenta raid — pero da al administrador del sistema flexibilidad: 
ampliar o reducir el espacio dedicado a cada uno de los volumenes, incluso en 
un sistema en produccion y con datos. 

Ademas de lo anterior, LVM ofrece varias funciones adicionales, como las 
fotograflas {snapshots) o varios esquemas de reemplazo de disco; si bien hay mu- 
cho mas que podrfa decirse de lvm, no se profundiza mas en esta herramienta 
dado que excede del objetivo del presente material. 
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C.3.2. ZFS 

Si bien LVM realiza una importante tarea de simplificacion en la administra- 
cion del sistema, su operacion sigue siendo orientada a bloques: los volumenes 
logicos deben aiin ser formateados bajo el sistema de archives que el adminis- 
trador del sistema considere acorde para la tarea requerida. 

El sistema de archives ZFS^ fue desarrollado por Sun Microsystems desde el 
ano 2001, forma parte del sistema operativo Solaris desde el 2005, y hoy en dia 
puede emplearse desde los principales sistemas operativos libres.^*^ Y si bien 
ZFS resulta suficientemente atractivo tan solo por haber sido disenado para que 
el usuario nunca mas se tope con uxi Hmite impuesto por el sistema operativo, 
el principal cambio que presenta al usuario es una forma completamente dis- 
tinta de referirse al almacenamiento. 

En primer termino, al igual que LVM presenta vma primer integracion en- 
tre conceptos, permitiendo unir de diferentes maneras varios dispositivos fisi- 
cos en un dispositive logico, ZFS incluye en la misma logica administrativa al 
sistema de archives: en la configuracion estandar, basta conectar una unidad 
al sistema para que esta aparezca como espacio adicional disponible para los 
usuarios. El espacio combinado de todas las imidades conforma \m fondo de 
almacenamiento {storage pool). 

La logica de ZFS parte de que operara una coleccion de sistemas de archives 
en una organizacion jerarquica. Pero a diferencia del esquema tradicional Unix 
en que cada sistema de archives es preparado desde tm principle para su fun- 
cion, en ZFS se pueden aplicar limites a jerarquias cempletas. Baje un esquema 
ZFS, la creacion y el mentaje de un sistema de archives es una operacion senci- 
11a — al grade que se presenta como recomendacion que, para cada usuario en 
el sistema, se genere \m sistema de archives nuevo e independiente. 

Una de las principales diferencias con los sistemas de archives tradicie- 
nales es el manejo del espacio vacio: el espacio disponible total del fondo de 
almacenamiento se reporta como disponible para todos los sistemas de archivos 
que formen parte de este. Sin embargo, se pueden indicar reservas (mantener 
un mmimo del espacio especificado disponible para determinado subconjunto 
de sistemas de archivos dentro de la coleccion) y Itmites (evitar que el uso de 
una coleccion exceda el almacenamiento indicado) para las necesidades de las 
diferentes regiones del sistema. 



^El nombre ZFS proviene de Zcttahyte File System. Los diseftadores de ZFS indican, sin embargo, 
que esto no es para indicar que ZFS sea capaz de direccionar hasta zettabytes de informacion, sino 
que sera el ultimo sistema de archivos que cualquier administrador requeriri. 

^"zvs no puede ser incorporado mtegramente al niicleo de Linux por incompatibilidad de licencias: 
si bien ambos son software libre, los modelos de Ucenciamiento GPL (de Linux) y CDDL (de ZFS) 
son incompatibles. 
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C.4. Ejercicios 

C.4.1. Preguntas de autoevaluacion 

1. Se presentaron algunos algoritmos para gestionar las solicitudes de ac- 
ceso a disco — Primero llegado, primero servido (FIFO), Tiempo mas corto 
a continuacion (SSTF), Elevador (SCAN), y algunas de sus variaciones. Se 
menciono tambien que, a pesar de la importancia de conocerlos por su 
rmportancia historica, hoy en dla han dejado de ser tan importantes co- 
mo lo fueron hacia los 1980. Mencione dos factores que han Uevado a que 
pierdan relevancia. 

2. Realice un esquema de como se estructura cada bloque de informacion 
sobre varios discos bajo raid niveles 0, 1 y 5. Para cada uno de estos 
niveles, indique el efecto que su empleo tendria en cuanto a espacio total, 
velocidad de acceso y confiabilidad. 

C.4.2. Temas de investigacion sugeridos 

Detalles de los sistemas de archives en Flash En este apendice se expusieron 
los principales puntos de los medios de estado sdlido o no rotativos, apun- 
tando apenas hacia como podrian. estos aprovecharse mejor. 

iQue sistemas de archivos estan mejor afinados para operar con medios 
Flash, y cuales son los principales obstaculos para que gocen de una ma- 
yor adopcion? 

C.4.3. Lecturas relacionadas 

■ OpenSolaris ZFS Deduplication: Everything You Need to Know 

http : / / constant in .glez.de/blog/2010/ 03/opensolaris-zf s-deduplicat ion-everything-you-need- 
Constantin Gonzalez (2010) 

■ The Z File System (ZFS) 

http : //www . f reebsd . org/doc/en_US . IS0885 9- 1/books /handbook/ filesystems-zfs . 
html 

FieeBSD Handbook 

■ A hash-based DoS attack on Btrfs 
http://lwn.net/Articles/529077/ 
Jonathan Corbet (2012); Liniix Weekly News 

■ 4K Sector Disk Drives: Transitioning to the Future with Advanced Format Tech- 
nologies 

http : / / storage . toshiba . com/ docs/ services- support-document s/toshiba_ 

4kwhitepaper . pdf 

Michael E. Fitzpatrick (2011); Toshiba 
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■ The Design and Implementation of a Log-Structured File System 
http : / /www . cs . berkeley . edu/ -brewer/ cs2 52 /LFS .pdf 

Mendel Rosenblum, J. K. Ousterhout (1992); ACM Transactions on Com- 
puter Systems 

■ LogFS — Finally a scalable flash file system 

http : / /www . inf ormat ik . uni-osnabrueck . de/papers_pdf /2 005_07 .pdf 
Jorn Engel, Robert Martens (2005) 

■ Log-structured file systems: There's one in every SSD 
https : //lwn.net/Articles/353411/ 
Valerie Aurora (2009); Linux Weekly News 

■ JFFS2, UBIFS, and the growth offiash storage 

http : //Iwn . net /Articles/52 8 617/ 
Neil Brown (2012); Linux Weekly News 

■ A case for Redundant Arrays of Inexpensive Disks 

http : / / www . cs . emu . edu/ -garth/RAIDpaper /Pattersons 8 . pdf 
Pati:erson, Gibson, Katz (1988); ACM SIGMOD 

■ Unidades de estado sdlido. El reto de la computacidn forense en el mundo de los 
semiconductores 

http://insecurityit. blogspot .nix/2 013/ 0 5/ 
Cano Martinez (2013); IT-Insecurity 

■ Non-volatile memory based on the ferroelectric photovoltaic effect 
http: //dx.doi .org/10 . 1038/ncomms2990 

Guo, You, Zhow et. al. (2013); Nature Commimications 

■ eMMC/SSD File System Tuning Methodology 

http : //elinux . org/images/b/b5/EMMC-SSD_File_System_Tuning_Methodology. 
vl . 0 .pdf 

Cogent Embedded (2013) 
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